Když jsou servery mimo provoz, může to vést k přerušení vašich obchodních cílů a vést ke ztrátě příjmů. Letecká společnost například nemusí být schopna rezervovat lety pro zákazníky, pokud nejsou k dispozici instance a databáze. Systémy mohou selhat z různých důvodů, jako je požár, lidská chyba, selhání počítače, selhání disku a chyby programování.
Aby se předešlo narušení a zajistila se kontinuita obchodních služeb, je nesmírně důležité mít strategie vysoké dostupnosti (HA) a obnovy po havárii (DR). HA a DR jsou často diskutovány společně. HA se zabývá co možná největším snížením prostojů serveru, ale protože žádný systém není dokonalý, DR se zaměřuje na proces použití záložního média k obnově ztracených dat v případě, že databázový systém selže.
AlwaysOn je značka/marketingový termín používaný od SQL Server 2012 k popisu vylepšených funkcí HADR společnosti Microsoft. Před AlwaysOn databázový stroj podporoval další, vestavěná proprietární řešení, jako je zrcadlení databáze, cluster s podporou převzetí služeb při selhání a odesílání protokolů. Každá z těchto technik však měla výhody a omezení. Často, v závislosti na svých cílech, musela organizace kombinovat více metod dohromady, aby dosáhla žádoucí strategie HADR.
Funkce AlwaysOn byly představeny, takže se nemusíte zabývat časem a zdroji navíc k implementaci a zavádění složitosti při implementaci, abyste zohlednili redundanci serveru i databáze, naráželi na problémy se škálováním nebo měli záložní hardware, který není efektivně využíván. Tyto funkce vhodně spojují mnoho starých postupů dohromady a zlepšují oblasti, kde zaostávaly. Chcete-li skutečně porozumět hodnotě nabídek AlwaysOn, je důležité znovu se podívat na původní základní koncepty toho, jak databázový stroj v minulosti zajišťoval systém HADR.
Zrcadlení databáze
Redundanci databáze lze dosáhnout pomocí zrcadlení. Můžete mít například klientskou aplikaci generující příjmy, která studentům umožňuje objednávat učebnice online. Zákazník si vybere svůj nákup a požadavky se odešlou do databáze PsychologyBooks na zadní straně. V případě katastrofy, která způsobí nedostupnost databáze PsychologyBooks, nebude student schopen dokončit svou objednávku.
Chcete-li se tomuto narušení vyhnout, můžete mít hlavní instanci nasazenou v produkci, která obsahuje databázi PsychologyBooks, a mít další kopii této databáze PsychologyBooks na zrcadleném serveru v pohotovostním režimu. Klientské aplikace se mohou znovu připojit k zrcadlené kopii, aniž by došlo k přerušení a musely čekat na dokončení obnovy na primární. Kopie udržuje krok se změnami provedenými na originálu tím, že přijímá protokoly transakcí a poté znovu provede tyto zaznamenané změny.
Relace zrcadlení mohou fungovat v různých režimech v závislosti na výkonu nebo zdůvodnění vysoké bezpečnosti. Pohodlně je podporováno automatické převzetí služeb při selhání, když je relace zrcadlení provozována ve vysoce bezpečném synchronním režimu a je dosaženo konsensu kvora s přítomností volitelného svědeckého serveru.
Navzdory výhodám zrcadlení zaostává, protože poskytuje pouze redundanci databáze, nikoli redundanci serveru. To znamená, že pokud dojde k výpadku instance primárního serveru, dojde k výpadku obou instancí a nezáleží na tom, že existuje náhradní kopie dat na úrovni databáze. Pohotovostní režim nepodporuje uživatelské operace a k získání kopie dat v zrcadlené instanci pouze pro čtení by byly potřeba snímky. Databáze je chráněna, ale objekty na úrovni serveru, jako je členství v roli serveru, přihlašovací údaje a úlohy agenta, chráněny nejsou.
Pokud by například existoval velký marketingový tým a každý člen měl své vlastní přihlašovací údaje, museli by znovu procházet procesem opětovného vytváření přihlašovacích údajů pro každou osobu. Když dojde k převzetí služeb při selhání, je to na základě nezávislé databáze a ne jako skupina.
Failover Clustering
Klastrování s podporou převzetí služeb při selhání nabízí redundanci na úrovni instance a poskytuje ochranu před selháním hardwaru a operačního systému. Řekněme například, že uzel v Queen Anne začne hořet a způsobí selhání zařízení. Celá instance – která zahrnuje objekty na úrovni instance, jako jsou přihlášení nebo specifické úlohy, které byly vytvořeny za účelem provádění konkrétních úloh – bude chráněna a může se automaticky restartovat na jiném uzlu patřícím do clusteru. Klientské aplikace a služby budou zákazníkům i nadále dostupné.
Výše uvedený scénář funguje, protože úložiště je sdíleno mezi redundantními fyzickými servery ve skupině Windows Server Failover Cluster (WSFC). Operační systém i SQL Server spolupracují, takže skupinu prostředků WSFC v daný okamžik vlastní pouze jeden uzel.
Bohužel s běžným úložištěm toto řešení neposkytuje redundanci databáze, kterou poskytovala dřívější strategie zrcadlení. Sdílené úložiště představuje riziko, protože vede k jedinému bodu selhání. Externí disky mohou například obsahovat jedinou kopii důležité databáze PsychologyBooks, a přestože instance úspěšně přešla do uzlu Ballard, stále by docházelo k přerušení plnění obchodních cílů, pokud by byla kompromitována jediná komponenta úložiště. Klastrování s podporou převzetí služeb při selhání také navrhuje omezení z hlediska škálovatelnosti, protože klientské aplikace nejsou schopny zvládnout rostoucí množství práce, která se rozšiřuje dále než cluster.
Zapsat zásilku
Další metodou, jak dosáhnout redundance databáze, je doprava protokolu. Protokoly transakcí jsou zálohovány na primární server a odeslány na jeden nebo více sekundárních serverů k obnovení. Na rozdíl od zrcadlení mohou být sekundární databáze způsobilé pro aktivitu pouze pro čtení a frekvenci odesílání protokolu lze konfigurovat pro různé intervaly. Ve scénářích, ve kterých sekundární databáze nemusí být nutně synchronizovány s primární databází v reálném čase, je výhoda výkonu.
Například spuštění statistického souhrnného hlášení na konci noci, abyste viděli, jaké knihy o psychologii se prodávají během dne, nevyžaduje, aby databáze kopií byla přesně synchronizována s primární databází. Činnost náročná na čtení zablokuje databázové objekty a může prodloužit čekací doby. Spouštění sestav na sekundárním serveru by tedy zmírnilo nároky na pracovní zátěž na primárním serveru generujícím příjmy.
Nevýhodou je, že odesílání protokolu nepodporuje automatické převzetí služeb při selhání. Pokud tedy selže zdrojový server, je třeba databázi obnovit ručně. Stejně jako zrcadlení ani odesílání protokolů neposkytuje redundanci serveru a je řešením na úrovni databáze.
Vysvětlení funkce AlwaysOn
Staré technologie mají každá své výhody a nevýhody. Implementace přizpůsobeného řešení HADR se však může rychle zkomplikovat a vyžadovat více správy, protože tyto různé strategie se libovolně kombinují a spojují, aby vyhovovaly obchodním potřebám. Proto byly představeny funkce AlwaysOn, které poskytují vylepšenou, již kombinovanou verzi předchozích strategií.
SQL Server nabízí dvě funkce:AlwaysOn Availability Groups (AG) a AlwaysOn Failover Cluster Instance (FCI). Oba vyžadují implementaci Windows Server Failover Clustering (WSFC).
AG je skupina databází, které společně přejdou při selhání. K hostiteli replik dostupnosti budete potřebovat několik redundantních fyzických uzlů s nainstalovanou instancí SQL Server na každém z uzlů. Každá replika musí být na jiném uzlu stejného WSFC. Ve schématu výše je primární replika hostována na uzlu 01 a všechny ostatní sekundární repliky jsou způsobilé pro převzetí služeb při selhání, když WSFC zjistí, že je problém.
Způsob, jakým sekundární repliky zůstávají synchronizované s primární, je odesílání protokolů transakcí a opakování změn. AG podporuje asynchronní i synchronní režim potvrzení. Primární replika je vhodná pro čtení a zápis, zatímco sekundární repliky jsou způsobilé pouze pro čtení. Zálohování lze provádět na sekundárním umístění.
S AlwaysOn AG okamžitě získáte výhody. Připomeňme si, že některé z nedostatků zrcadlení databáze jsou, že databázi lze zrcadlit pouze na jeden sekundární server a že když dojde k převzetí služeb při selhání, je každá databáze zrcadlena nezávisle. Díky AG jsou databáze na mnoha místech nadbytečné, jako je uzel 02, uzel 03, uzel 04 a uzel 05 ve výše uvedeném příkladu. Podpora dostupnosti databáze umožňuje až devět replik dostupnosti.
Kromě toho by bylo nutné zaslání protokolu k dosažení dat pouze pro čtení na sekundárním serveru. Ale u AG jsou již započítána data pouze pro čtení. Činnosti náročné na čtení, jako je hlášení, lze provádět na kterékoli ze sekundárních replik. Všimněte si také, že neexistuje žádné omezení sdíleného úložiště.
AG však lze kombinovat s AlwaysOn FCI, aby byla umožněna redundance serveru. Instance FCI může být použita k hostování replik dostupnosti, takže objekty na úrovni serveru, jako jsou přihlášení a úlohy agentů, mohou být také chráněny. Tento přístup bude vyžadovat sdílené úložiště. Budou však odstraněny nepříjemnosti, jako je nutnost provádět změny konfigurace klientských aplikací.