Zawsze lubię wizualizować rozwiązania wysokiej dostępności:
SQL Server Failover Cluster Instance (FCI)
Co jest wysoce dostępne? Cała instancja. Obejmuje to wszystkie obiekty serwera (loginy, zadania agenta SQL Server itp.). Dotyczy to również baz danych i ich zawierających jednostek. Jest to świetne rozwiązanie dla wysoce dostępnych instancji SQL Server, ponieważ będzie to poziom zabezpieczenia przed tym danym rozwiązaniem.
Co z raportowaniem? Brak, NULL, nieistniejący. Instancja klastra pracy awaryjnej ma aktywny węzeł dostarczający grupę klastrów zawierającą instancję, VNN itp., A wszystkie inne węzły są pasywne, siedzą bezczynnie (w odniesieniu do bieżącej grupy klastrów) i czekają na przełączenie awaryjne.
Co się stanie, gdy nastąpi przełączenie awaryjne? Przestój dla FCI będzie zależał od czasu, jaki węzeł pasywny potrzebuje, aby pobrać zasób klastra i doprowadzić instancję programu SQL Server do działania. Zazwyczaj jest to minimalny czas.
Jakaś abstrakcja klienta? Tak, będzie to wewnętrznie wbudowane w nazwę sieci wirtualnej dla instancji klastra pracy awaryjnej. To zawsze będzie wskazywać na aktywny węzeł, który obecnie dostarcza zasób klastra SQL Server.
Grupy dostępności AlwaysOn
Co jest wysoce dostępne? Grupa dostępności będzie tutaj logicznym zabezpieczeniem wysokiej dostępności, podczas gdy grupa dostępności składa się z wielu baz danych i nazwy sieci wirtualnej (detektor, opcjonalny zasób klastra). Warto zauważyć, że obiekty serwera, takie jak loginy i zadania agenta SQL Server, nie będą częścią rozwiązania wysokiej dostępności i należy zwrócić szczególną uwagę, aby zapewnić ich prawidłowe wdrożenie z grupą dostępności. Nie jest to zbyt obciążający wymóg, ale należy się nim zająć.
Co z raportowaniem? To świetne rozwiązanie do raportowania, chociaż prawdopodobnie nie użyłbym repliki synchronicznej jako mojej instancji raportowania. Istnieją dwie zależności zatwierdzania, synchroniczna i asynchroniczna. Moim zdaniem i z tego, co widziałem w praktyce, jest to, że twoja synchroniczna replika wtórna czeka na katastrofę. Pomyśl o tym jako o replice, która jest gotowa na przełączenie awaryjne bez utraty danych w razie problemu. Są też repliki asynchroniczne, które mogą obsłużyć to obciążenie raportowaniem. Nie używasz tej repliki jako wyżej wspomnianego rozwiązania, ale możesz zrobić coś takiego jak raportowanie. Obciążenia raportowania można skierować do tej repliki (bezpośrednio lub pośrednio poprzez routing tylko do odczytu za pośrednictwem nasłuchiwania).
Co się stanie, gdy nastąpi przełączenie awaryjne? W przypadku repliki wtórnej synchronicznego zatwierdzania sparowanej z automatycznym przełączaniem awaryjnym będzie to zmiana stanu roli repliki z SECONDARY_NORMAL na PRIMARY_NORMAL. Aby możliwe było automatyczne przełączanie awaryjne, musisz mieć synchroniczną replikę pomocniczą, która jest obecnie zsynchronizowana, a zaimplementowane są elastyczne zasady przełączania awaryjnego w celu ustalenia, kiedy faktycznie powinno nastąpić przełączenie awaryjne. Ta polityka jest rzeczywiście konfigurowalna.
Jakaś abstrakcja klienta? Tak, możesz opcjonalnie skonfigurować odbiornik AlwaysOn Availability Group. Jest to po prostu nazwa sieci wirtualnej (może być postrzegana przez WSFC jako zasób klastra w grupie klastrów AG), która wskazuje na bieżącą replikę podstawową. Jest to kluczowa część przesunięcia obciążenia raportowaniem, a także skonfigurowania listy routingu tylko do odczytu na wszystkich serwerach, które mają przekierowywać ruch ReadOnly (jest to ustawiane za pomocą ciągu połączenia za pomocą .NET Framework Provider for SQL Serwer, będzie to parametr Cel aplikacji , ustawiony na Tylko do odczytu ). Konieczne będzie również ustawienie adresu URL routingu tylko do odczytu dla każdej repliki, która ma otrzymać to obciążenie raportowaniem podczas pełnienia roli dodatkowej repliki.
Transakcyjna replikacja
Co jest wysoce dostępne? To jest dyskusyjne, ale nie powiem nic . Nie uważam replikacji za rozwiązanie wysokiej dostępności. Tak, zmiany danych są przekazywane subskrybentom, ale mówimy na poziomie publikacji / artykułu. Będzie to podzbiór danych (może obejmować wszystkie dane, ale nie zostanie to wymuszone. Tj. Utworzysz nową tabelę w bazie danych wydawcy, która nie zostanie automatycznie przekazana subskrybentom). Jeśli chodzi o HA, jest to dno lufy i nie będę go tam grupować z solidnym roztworem HA.
Co z raportowaniem? Świetne rozwiązanie do raportowania podzbioru danych, nie ma co do tego wątpliwości. Jeśli masz bazę danych o wielkości 1 TB, która jest wysoce transakcyjna i chcesz utrzymać obciążenie raportowaniem poza bazą danych OLTP, replikacja transakcyjna to świetny sposób na przekazanie podzbioru danych subskrybentowi (lub subskrybentom) w celu obciążenia raportowaniem. Co się stanie, jeśli z 1 TB danych obciążenie raportowaniem wynosi tylko około 50 GB? To inteligentne rozwiązanie i stosunkowo konfigurowalne w celu spełnienia potrzeb biznesowych.
Podsumowanie
Sprowadza się do kilku pytań, na które należy odpowiedzieć (częściowo przez biznes):
- Co musi być wysoce dostępne ?
- Co dyktuje SLA dla HA / DR?
- Jakiego rodzaju raportowanie będzie miało miejsce i jakie opóźnienia są dopuszczalne?
- Co musimy poradzić sobie z rozproszonym geograficznie HA? (replikacja magazynu jest kosztowna, ale musi być wymagana w przypadku FCI. AG nie wymagają pamięci współdzielonej z niezależnych instancji, a można użyć świadka udostępniania plików do kworum potencjalnie eliminującego potrzebę współdzielonego przechowywania)
Jaki rodzaj obciążenia? „To zależy” - ale poważnie, jest to przydatne w przypadku aplikacji online, w której musisz mieć lokalne centrum danych o wysokiej dostępności. Jesteś chroniony przed awarią jednego komputera lub jednego systemu operacyjnego. Loginy, zadania, nowe bazy danych, konserwacja itp. Są automatycznie synchronizowane przez fakt, że jest to klaster z dwoma węzłami, które są dokładnie takie same, współużytkują tę samą pamięć masową, więc mają wszystkie te same systemowe bazy danych. Bardzo szybkie przełączanie awaryjne, ale nadal występuje czkawka, która wygląda jak ponowne uruchomienie SQL Server po wystąpieniu przełączenia awaryjnego.
Wady / obawy - jednym punktem awarii jest pamięć masowa i wszystkie jej komponenty. Dostawcy sieci SAN zawsze mówią „sieci SAN nie zawodzą”, ale w sieci pamięci masowej jest wiele ruchomych części, a jak pisałem tutaj na blogu , mogą. Ponadto - płacisz za serwer pomocniczy, który nie może zrobić nic innego, jak tylko siedzieć i czekać. Teraz możesz zrobić Aktywny / Aktywny / Multi-Węzeł i mieć dwie aktywne instancje, które mogą pracować w trybie failover w dowolnym kierunku i korzystać z drugiego węzła.
Automatyczne przełączanie awaryjne? „Najbardziej” automatyczny. Nie potrzeba świadka, to klaster. To jest zadanie klastra, aby uczynić go tak płynnym, jak to możliwe. Teraz z każdym z nich, kiedy nastąpi awaria, poczujesz to, ponieważ SQL musi się uruchomić lub połączenia muszą wskazywać. Kiedy to się stanie, poczujesz się jak ponowne uruchomienie SQL, bazy danych wrócą i uruchomią odzyskiwanie / etc.
Jeśli mam klienta, który mówi: „Chcę w pełni korzystać ze wszystkich baz danych, wszystkich danych logowania itp.” W środowisku wysokiej dostępności w moim lokalnym centrum danych, ponieważ mam niewiarygodnie niską tolerancję na przestoje, rozważę wystąpienia klastra pracy awaryjnej (chociaż ostatnia opcja, o której wspominasz, jest silnym konkurentem, z wyjątkiem konieczności wykonania pewnych ogólnych kosztów zarządzania). Prawdopodobnie zrobiłbym lokalny FCI i asynchronizację AG jako pomocniczą w celu ochrony przed awarią witryny lub awarią SAN.
Właśnie w ten sposób pomagam ludziom wdrażać coraz więcej, choć czasem wciąż chodzę do grupowania.
Podsumowanie
HA i DR są różne. Technologie te pomagają zapewnić jedno z nich. Wysoka dostępność oznacza (dla mnie), że możesz szybko odzyskać, jeśli coś złego stanie się z jedną maszyną, masz krótki cel przywracania i cel przywracania. To jest klastrowanie i synchroniczna AG.
Disaster Recovery to „możesz wstać, gdy masz awarię nawet w swoim rozwiązaniu HA. Dla mnie mogą to być AG, kiedy idziesz do innego centrum danych, dublowania, a nawet replikacji.
źródło
Ważne jest również, aby wziąć pod uwagę, co jest udostępniane .
Klaster pracy awaryjnej używa dwóch lub więcej węzłów serwera współdzielących jedną macierz dyskową. Jeśli macierz dyskowa ulegnie awarii, utracisz usługę, bez względu na liczbę węzłów serwera. Jeśli serwerownia, w której znajduje się ta macierz dyskowa, zapali się lub zostanie zalana, oznacza to utratę usługi.
Grupy AlwaysOn Availability i Mirroring bazy danych to technologia klastrowania „nic wspólnego”. Baza danych jest obecna na wielu macierzach dyskowych na wielu serwerach. Jeśli masz dobre łącza sieciowe, wiele serwisów może znajdować się w wielu serwerowniach, chroniąc Cię przed pożarami i powodziami.
źródło
Dla kompletności istnieje opcja użycia zwykłego starego zapisu lustrzanego. Zalety obejmują dwie kopie bazy danych bez złożoności korzystania z grup dostępności i bez potrzeby współdzielonej pamięci masowej dla klastra pracy awaryjnej. Wadą, choć niewielką, jest to, że tworzenie kopii lustrzanych jest przestarzałe.
Czasy przełączania awaryjnego z kopią lustrzaną są rzędu 10 sekund, chociaż kod aplikacji musi być w stanie ponawiać wszelkie transakcje występujące w momencie przełączania awaryjnego.
źródło