Zakładając, że musisz upewnić się, że aplikacja oparta na programie SQL Server 2012, ponieważ jej zaplecze bazy danych jest dostępne przez całą dobę, nawet w przypadku awarii jednego serwera.

Jako programista, a nie DBA, staram się zrozumieć, kiedy użyć scenariusza mojej pracy awaryjnej / wysokiej dostępności:

• Dwa (lub więcej) serwerów w klastrze pracy awaryjnej systemu Windows, SQL Server jako instancja klastrowa
• Dwa (lub więcej) wystąpienia programu SQL Server, które są aktualizowane dzięki replikacji transakcyjnej
• Dwa (lub więcej) serwery SQL w grupie dostępności programu SQL Server, skonfigurowane w trybie zatwierdzania synchronicznego

Który z tych scenariuszy działa przy danym obciążeniu i jakiego rodzaju awarie / awarie mogą być obsługiwane przez te scenariusze? Czy są nawet porównywalne / wymienne?

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):

1. Co musi być wysoce dostępne ?
2. Co dyktuje SLA dla HA / DR?
3. Jakiego rodzaju raportowanie będzie miało miejsce i jakie opóźnienia są dopuszczalne?
4. 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)

dwa (lub więcej) serwerów w klastrze pracy awaryjnej systemu Windows, SQL Server jako instancja klastrowa

1. 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.

2. 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.

3. 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.

dwa (lub więcej) wystąpienia programu SQL Server, które są aktualizowane dzięki replikacji transakcyjnej

1. Jaki rodzaj obciążenia? Szczerze mówiąc, nie wybrałbym tutaj wielu przypadków potrzeby wysokiej dostępności lub odzyskiwania po awarii jako pierwszego wyboru. Na pewno nie w SQL 2012. Ale w zasadzie jest to dobre, jeśli musisz udać się do centrum danych, które nie było blisko, nie możesz użyć AG (być może problem z domeną uniemożliwia ci korzystanie z klastra Windows wymaganego dla AG), być może chciałbyś być w standardzie SQL Server, który może wykonywać replikację, ale nie AG, ale nadal chcesz mieć możliwość czytania po stronie wtórnej i być asynchronicznym.
2. Wady / wątpliwości - To replikacja. Ma narzut, może się zsynchronizować, możesz mieć problemy z wydajnością po stronie źródła itp.
3. Automatyczne przełączanie awaryjne - Nie. Musisz sam to zarządzać. Albo za pośrednictwem CNAME, które wskazują na jeden lub drugi, i możesz teoretycznie napisać własny proces, aby to zrobić, ale po wyjęciu z pudełka? Uwaga tutaj.

dwa (lub więcej) serwery SQL w grupie dostępności programu SQL Server, skonfigurowane w trybie zatwierdzania synchronicznego

Właśnie w ten sposób pomagam ludziom wdrażać coraz więcej, choć czasem wciąż chodzę do grupowania.

1. Jaki rodzaj obciążenia? Jest to świetne, gdy mam zarządzalny zestaw baz danych do synchronizacji, a zasoby i czas, aby upewnić się, że zadania, loginy, nowe bazy danych itp. Pozostaną zsynchronizowane (chociaż zespół SQL Skills ma świetny dodatek do zautomatyzuj niektóre z nich, aby uczynić go jeszcze silniejszym z opcji). Podoba mi się to, gdy chcę całkowicie oddzielić rzeczy. Chronię przed problemami sprzętowymi, problemami z systemem operacyjnym, problemami z instalacją SQL, problemami z poprawkami oraz problemami z siecią SAN / Storage. Korzystam również z możliwości posiadania dodatkowego (jeśli chcę za to zapłacić licencji przedsiębiorstwa), aby być aktywnym dodatkowym, z którego mogę czytać, tworzyć kopie zapasowe itp. Plus w przyszłości mogę dodać trzeci pomocniczy, który jest asynchroniczny w zdalnej lokacji i ma tryb failover / DR.
2. Wady / obawy Licencjonowanie, maksymalna liczba replik, koszty licencjonowania, aby skorzystać z jednych z największych korzyści (aktywnych drugorzędnych), wymaga przedsiębiorstwa, wymaga dwa razy więcej pamięci niż klastrowania.
3. Automatyczne przełączanie awaryjne - Tak. Może się to zdarzyć przy konfiguracji świadka, a programiści aplikacji mogą łączyć się z detektorem zamiast z węzłem, więc przełączanie awaryjne następuje w miejscu, w którym detektor wskazuje i powinieneś być dobry. Tak, możesz to zrobić tutaj - i powinieneś - ale oczywiście powinieneś to dobrze przetestować.

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.

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.

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.