Awaria serwerów może prowadzić do przerw w realizacji celów biznesowych i spowodować utratę przychodów. Na przykład linia lotnicza może nie być w stanie zarezerwować lotów dla klientów, jeśli instancje i bazy danych nie są dostępne. Systemy mogą ulec awarii z różnych powodów, takich jak pożar, błędy ludzkie, awarie komputerów, awarie dysków i błędy programowania.
Aby uniknąć zakłóceń i zapewnić ciągłość usług biznesowych, niezwykle ważne jest wdrożenie strategii wysokiej dostępności (HA) i odzyskiwania po awarii (DR). HA i DR są często omawiane razem. HA zajmuje się jak największym skróceniem przestojów serwera, ale ponieważ żaden system nie jest doskonały, DR koncentruje się na procesie wykorzystania nośnika kopii zapasowej do odzyskania utraconych danych w przypadku awarii systemu bazy danych.
AlwaysOn to termin dotyczący marki/marketingu używany od SQL Server 2012 do opisu ulepszonych funkcji HADR firmy Microsoft. Przed AlwaysOn aparat bazy danych obsługiwał inne, wbudowane, zastrzeżone rozwiązania, takie jak dublowanie baz danych, klaster pracy awaryjnej i wysyłanie dzienników. Jednak każda z tych technik miała swoje zalety i ograniczenia. Często, w zależności od swoich celów, organizacja musiała łączyć ze sobą wiele metod, aby osiągnąć pożądaną strategię HADR.
Wprowadzono funkcje AlwaysOn, dzięki czemu nie musisz zajmować się dodatkowym czasem i zasobami, aby wdrożyć i wprowadzić złożoność wdrażania, aby uwzględnić nadmiarowość serwera i bazy danych, napotkać problemy ze skalowaniem lub mieć sprzęt w stanie gotowości, który nie jest efektywnie używany. Te cechy w wygodny sposób łączą wiele starych praktyk i poprawiają obszary, w których się nie sprawdzały. Aby naprawdę zrozumieć wartość ofert AlwaysOn, ważne jest ponowne przyjrzenie się początkowym, fundamentalnym koncepcjom, w jaki sposób silnik bazy danych zapewniał systemowi HADR w przeszłości.
Odbicie lustrzane bazy danych
Nadmiarowość bazy danych można osiągnąć poprzez dublowanie. Na przykład możesz mieć generującą przychody aplikację kliencką typu front-end, która umożliwia uczniom zamawianie podręczników online. Klient wybiera swój zakup, a prośby są kierowane do bazy danych PsychologyBooks na zapleczu. W przypadku katastrofy, w wyniku której baza danych PsychologyBooks jest niedostępna, student nie będzie mógł zrealizować zamówienia.
Aby uniknąć tych zakłóceń, można wdrożyć w środowisku produkcyjnym główną instancję, która zawiera bazę danych PsychologyBooks i mieć dodatkową kopię tej bazy danych PsychologyBooks na serwerze lustrzanym w trybie gotowości. Aplikacje klienckie mogą ponownie łączyć się z kopią lustrzaną, zamiast doświadczać przerw i czekać na zakończenie odzyskiwania na kopii podstawowej. Kopia nadąża za zmianami wprowadzonymi w oryginale, odbierając dzienniki transakcji, a następnie ponawiając zarejestrowane zmiany.
Sesje dublowania mogą działać w różnych trybach w zależności od wydajności lub uzasadnień wysokiego bezpieczeństwa. Dogodnie jest obsługiwane automatyczne przełączanie awaryjne, gdy sesja dublowania działa w trybie synchronicznym o wysokim poziomie bezpieczeństwa, a konsensus kworum jest ustalany z opcjonalnym serwerem-świadkiem.
Pomimo korzyści płynących z dublowania, jest niewystarczający, ponieważ zapewnia tylko nadmiarowość bazy danych, a nie nadmiarowość serwera. Oznacza to, że jeśli instancja serwera podstawowego ulegnie awarii, obie instancje ulegną awarii i nie ma znaczenia, że istnieje zapasowa kopia danych na poziomie bazy danych. Tryb gotowości nie obsługuje operacji użytkownika, a migawki byłyby potrzebne, aby uzyskać kopię tylko do odczytu danych z dublowanej instancji. Baza danych jest chroniona, ale obiekty na poziomie serwera, takie jak członkostwo w roli serwera, informacje logowania i zadania agenta, już nie.
Na przykład, gdyby istniał duży zespół marketingowy i każdy członek miałby swój własny login, musieliby przejść przez proces ponownego tworzenia loginów dla każdej osoby. Kiedy nastąpi przełączenie awaryjne, odbywa się to na podstawie niezależnej bazy danych, a nie jako grupa.
Klaster pracy awaryjnej
Klastry pracy awaryjnej zapewniają nadmiarowość na poziomie instancji i zapewniają ochronę przed awariami sprzętu i systemu operacyjnego. Na przykład, powiedzmy, że węzeł w Queen Anne zapala się, powodując awarię sprzętu. Cała instancja — która obejmuje obiekty na poziomie instancji, takie jak loginy lub określone zadania, które zostały utworzone w celu wykonania określonych zadań — będzie chroniona i może zostać automatycznie zrestartowana na innym węźle należącym do klastra. Aplikacje i usługi klienckie będą nadal dostępne dla klientów.
Powyższy scenariusz działa, ponieważ magazyn jest współużytkowany przez nadmiarowe serwery fizyczne w grupie Windows Server Failover Cluster (WSFC). Zarówno system operacyjny, jak i SQL Server współpracują ze sobą, dzięki czemu tylko jeden węzeł jest jednocześnie właścicielem grupy zasobów WSFC.
Niestety, w przypadku wspólnej pamięci masowej to rozwiązanie nie zapewnia nadmiarowości bazy danych, którą zapewniała wcześniejsza strategia dublowania. Posiadanie współdzielonej pamięci masowej wiąże się z ryzykiem, ponieważ skutkuje pojedynczym punktem awarii. Na przykład dyski zewnętrzne mogą zawierać jedyną kopię ważnej bazy danych PsychologyBooks i pomimo tego, że instancja została pomyślnie przełączona do węzła Ballard, nadal będzie miała miejsce przerwa w realizacji celów biznesowych, jeśli zostanie naruszony jedyny składnik pamięci masowej. Klastry pracy awaryjnej oferują również ograniczenia pod względem skalowalności, ponieważ aplikacje klienckie nie są w stanie obsłużyć rosnącej ilości pracy, która rozszerza się dalej niż klaster.
Wysyłka dziennika
Inną metodą uzyskania nadmiarowości bazy danych jest przesyłanie dzienników. Dzienniki transakcji są archiwizowane na serwerze głównym i wysyłane do jednego lub wielu serwerów pomocniczych w celu przywrócenia. W przeciwieństwie do dublowania, pomocnicze bazy danych mogą kwalifikować się do działania tylko do odczytu, a częstotliwość wysyłania dziennika można skonfigurować dla różnych interwałów. W scenariuszach, w których pomocnicze bazy danych niekoniecznie muszą być zsynchronizowane z podstawową bazą danych w czasie rzeczywistym, występuje korzyść w zakresie wydajności.
Na przykład, sporządzanie statystycznego raportu podsumowującego pod koniec nocy, aby zobaczyć, jakie książki psychologiczne są sprzedawane w ciągu dnia, nie wymaga, aby kopia bazy danych była dokładnie zsynchronizowana z podstawową bazą danych. Aktywność intensywnie odczytująca blokuje obiekty bazy danych i może wydłużyć czas oczekiwania. Dlatego uruchamianie raportowania na serwerze pomocniczym zmniejszyłoby obciążenie pracą na głównym serwerze generującym przychody.
Wadą jest to, że wysyłanie dziennika nie obsługuje automatycznego przełączania awaryjnego. Dlatego też, jeśli serwer źródłowy ulegnie awarii, bazę danych należy odzyskać ręcznie. Podobnie jak dublowanie, wysyłanie dziennika nie zapewnia nadmiarowości serwera i jest rozwiązaniem na poziomie bazy danych.
Zrozumienie funkcji AlwaysOn
Każda ze starych technologii ma swoje zalety i kompromisy. Jednak wdrożenie niestandardowego rozwiązania HADR może szybko stać się skomplikowane i wymagać większego zarządzania, ponieważ te różne strategie są dowolnie mieszane i dopasowywane do siebie w celu zaspokojenia potrzeb biznesowych. Dlatego wprowadzono funkcje AlwaysOn, które zapewniają ulepszoną, już połączoną wersję poprzednich strategii.
SQL Server oferuje dwie funkcje:AlwaysOn Availability Groups (AG) i AlwaysOn Failover Cluster Instances (FCI). Oba wymagają zaimplementowania Windows Server Failover Clustering (WSFC).
AG to grupa baz danych, które będą działać razem w trybie awaryjnym. Będziesz potrzebować kilku nadmiarowych węzłów fizycznych z instancją SQL Server zainstalowaną na każdym z węzłów do obsługi replik dostępności. Każda replika musi znajdować się w innym węźle tego samego WSFC. Na powyższym schemacie replika główna jest hostowana na węźle 01, a wszystkie pozostałe repliki pomocnicze kwalifikują się do przełączenia awaryjnego, gdy WSFC wykryje problem.
Sposób, w jaki repliki pomocnicze pozostają zsynchronizowane z podstawowym, polega na wysyłaniu dzienników transakcji i ponownym wprowadzaniu zmian. AG obsługuje zarówno asynchroniczny, jak i synchroniczny tryb zatwierdzania. Replika podstawowa nadaje się do odczytu i zapisu, natomiast repliki pomocnicze są przeznaczone tylko do odczytu. Kopie zapasowe można wykonywać w lokalizacji dodatkowej.
Zawsze pojawiają się korzyści z AlwaysOn AG. Przypomnijmy wcześniej, że niektóre z wad dublowania bazy danych polegają na tym, że bazę danych można dublować tylko na jednym serwerze pomocniczym i że w przypadku przełączenia awaryjnego każda baza danych jest dublowana niezależnie. Dzięki AG bazy danych są nadmiarowe w wielu miejscach, takich jak Węzeł 02, Węzeł 03, Węzeł 04 i Węzeł 05 w powyższym przykładzie. Obsługa dostępności bazy danych umożliwia do dziewięciu replik dostępności.
Ponadto przesyłanie dziennika byłoby konieczne, aby uzyskać dane tylko do odczytu na serwerze pomocniczym. Ale w przypadku AG dane tylko do odczytu są już uwzględnione. Czynności wymagające intensywnego odczytu, takie jak raportowanie, mogą być wykonywane na dowolnej z replik pomocniczych. Należy również zauważyć, że nie ma ograniczenia pamięci współużytkowanej.
Jednak AG można połączyć z AlwaysOn FCI, aby zapewnić nadmiarowość serwerów. Instancja FCI może służyć do hostowania replik dostępności, dzięki czemu można również chronić obiekty na poziomie serwera, takie jak loginy i zadania agenta. Takie podejście będzie wymagało współdzielonej pamięci masowej. Jednak niedogodności, takie jak konieczność wykonywania rekonfiguracji aplikacji klienckich, zostaną wyeliminowane.
