Wymagania wstępne, ograniczenia i zalecenia dotyczące grup dostępności Always On

Dotyczy:programu SQL Server

W tym artykule opisano zagadnienia dotyczące wdrażania grup dostępności Always On, w tym wymagań wstępnych, ograniczeń i zaleceń dotyczących komputerów hostów, klastrów trybu failover systemu Windows Server (WSFC), instancji serwerów i grup dostępności. Dla każdego z tych składników zagadnienia dotyczące zabezpieczeń i wymaganych uprawnień, jeśli istnieją, są wskazane.

Poprawki platformy .NET, które obsługują grupy dostępności

W zależności od składników i funkcji programu SQL Server, których będziesz używać z zawsze włączonymi grupami dostępności, może być konieczne zainstalowanie dodatkowych poprawek platformy .NET zidentyfikowanych w poniższej tabeli. Poprawki można zainstalować w dowolnej kolejności.

Lista kontrolna: Wymagania (system Windows)

Aby wspierać funkcję grupy dostępności Always On, upewnij się, że każdy komputer, który ma uczestniczyć w co najmniej jednej grupie dostępności, spełnia następujące podstawowe wymagania:

Zalecenia dotyczące komputerów hostujących repliki dostępności (system Windows)

• Porównywalne systemy: Dla danej grupy dostępności wszystkie repliki dostępności powinny być uruchomione na porównywalnych systemach, które mogą obsługiwać identyczne obciążenia.

• Dedykowane karty sieciowe: Aby uzyskać najlepszą wydajność, użyj dedykowanej karty sieciowej dla grup dostępności Always On.

• Wystarczająca ilość miejsca na dysku: Każdy komputer, na którym instancja serwera hostuje replikę dostępności, musi mieć wystarczająco dużo miejsca na dysku dla wszystkich baz danych w grupie dostępności. Pamiętaj, że wraz ze wzrostem podstawowych baz danych ich pomocnicze bazy danych rosną w tej samej ilości.

• Identyczny układ dysku: Każdy komputer, na którym wystąpienie serwera hostuje replikę dostępności, powinien mieć identyczny układ dysku (z dokładnymi literami dysków i rozmiarami), aby upewnić się, że ścieżki plików bazy danych (mdf, ldf) są dublowane, zapobiegając komplikacjom podczas rozmieszczania i synchronizacji. Przejrzyj Ograniczenia dotyczące baz danych dostępności dla układów dysków, które się różnią.

• Konfiguracja zarządcy zasobów: Jeśli używasz zarządcy zasobów, użyj tej samej konfiguracji zarządcy zasobów we wszystkich wystąpieniach hostujących repliki grup dostępności.

Uprawnienia (system Windows)

Aby administrować usługą WSFC, użytkownik musi być administratorem systemu w każdym węźle klastra.

Aby uzyskać więcej informacji na temat konta do administrowania klastrem, zobacz w Dodatek A: Wymagania klastra przełączania awaryjnego.

Powiązane zadania (system Windows)

Zmienianie wartości HostRecordTTL (przy użyciu programu PowerShell)

1. Otwórz okno programu PowerShell za pomocą Uruchom jako administrator.

2. Zaimportuj moduł FailoverClusters.

3. Użyj polecenia cmdlet Get-ClusterResource, aby znaleźć zasób Nazwa sieciowa, a następnie użyj polecenia cmdlet Set-ClusterParameter, aby ustawić wartość HostRecordTTL w następujący sposób:

   Get-ClusterResource "<NazwaZasobuSieciowego>" | Set-ClusterParameter HostRecordTTL <CzasWSekundach>

   Poniższy przykład programu PowerShell ustawia wartość HostRecordTTL na 300 sekund dla zasobu Nazwa sieci o nazwie SQL Network Name (SQL35).

   Import-Module FailoverClusters
   
   $nameResource = "SQL Network Name (SQL35)"
   Get-ClusterResource $nameResource | Set-ClusterParameter HostRecordTTL 300
   

   Napiwek

   Za każdym razem, gdy otworzysz nowe okno programu PowerShell, musisz zaimportować moduł FailoverClusters.

Powiązana zawartość (PowerShell)

• Klastrowanie i wysoka dostępność (blog zespołu ds. klastrowania trybu awaryjnego i równoważenia obciążenia sieciowego)

• Wprowadzenie do programu Windows PowerShell na klastrze z trybem przełączania awaryjnego

• polecenia zasobów klastra i równoważne polecenia cmdlet programu Windows PowerShell

Powiązana zawartość (system Windows)

• konfigurowanie ustawień DNS w klastrze trybu failover z wieloma lokacjami

• rejestracja DNS przy użyciu zasobu nazwy sieciowej

Wymagania wstępne i ograniczenia dotyczące wystąpienia programu SQL Server

Każda grupa dostępności wymaga zestawu partnerów trybu awaryjnego, znanych jako repliki dostępności , które są hostowane przez instancje SQL Server. Danym wystąpieniem serwera może być wystąpienie autonomiczne lub wystąpienie klastra trybu failover programu SQL Server (FCI).

W tej sekcji:

• lista kontrolna : wymagania wstępne
• użycie wątku według grup dostępności
• uprawnienia
• Powiązane zadania
• Zawartość powiązana

Lista kontrolna: Wymagania wstępne (instancja serwera)

Aby uzyskać listę funkcji obsługiwanych przez wersje programu SQL Server w systemie Windows, zobacz:

• Edycje oraz obsługiwane funkcje SQL Server 2022
• Edycje oraz obsługiwane funkcje programu SQL Server 2019
• Wersje i obsługiwane funkcje SQL Server 2017
• Wersje i obsługiwane funkcje programu SQL Server 2016

Użycie wątku według grup dostępności

Zawsze włączone grupy dostępności mają następujące wymagania dotyczące wątków roboczych:

• Na bezczynnym wystąpieniu programu SQL Server, grupy dostępności Always On używają 0 wątków.

• Maksymalna liczba wątków używanych przez grupy dostępności to skonfigurowane ustawienie maksymalnej liczby wątków serwera ("maksymalnych wątków roboczych") minus 40.

• Repliki dostępności hostowane w danym wystąpieniu serwera korzystają z jednej wspólnej puli wątków w programie SQL Server 2019 (15.x) i poprzednich wersjach.

  Wątki są udostępniane na żądanie w następujący sposób:

  • Zazwyczaj jest od 3 do 10 współdzielonych wątków, ale ta liczba może wzrosnąć w zależności od obciążenia głównej repliki.

  • Jeśli dany wątek jest bezczynny przez pewien czas, zostanie on zwolniony z powrotem do ogólnej puli wątków programu SQL Server. Zwykle nieaktywny wątek jest zwalniany po około 15 sekundach braku aktywności. Jednak, w zależności od ostatniego działania, wątek bezczynny może być zachowywany dłużej.

  • Wystąpienie programu SQL Server używa maksymalnie 100 wątków do równoległego ponownego uruchamiania replik pomocniczych. Każda baza danych używa maksymalnie jednej połowy całkowitej liczby rdzeni procesora CPU, ale nie więcej niż 16 wątków na bazę danych. Jeśli łączna liczba wymaganych wątków dla pojedynczego wystąpienia przekracza 100, program SQL Server używa pojedynczego wątku ponownego wykonania dla każdej pozostałej bazy danych. Wątki ponownej serii są zwalniane po około 15 sekundach braku aktywności.

• Ponadto grupy dostępności używają nieudostępnianych wątków w następujący sposób:

  • Każda replika podstawowa używa 1 wątku przechwytywania dziennika dla każdej podstawowej bazy danych. Ponadto używa 1 wątku wysyłania dziennika dla każdej pomocniczej bazy danych. Wątki wysyłania dziennika są zwalniane po około 15 sekundach braku aktywności.

  • Kopia zapasowa na replice drugorzędnej przechowuje wątek w replice podstawowej na czas operacji tworzenia kopii zapasowej.

• Program SQL Server 2022 (16.x) wprowadził równoległą pulę wątków odtwarzania, która jest pulą wątków na poziomie wystąpienia udostępnioną wszystkim bazom danych mającym zadania odtwarzania. W przypadku tej puli ten sam zestaw wątków może przetwarzać rekordy dziennika dla różnych baz danych w tym samym czasie (równolegle). W programie SQL Server 2019 (15.x) i poprzednich wersjach liczba dostępnych wątków dla powtórzeń jest ograniczona do 100.

• Program SQL Server 2019 (15.x) wprowadził równoległe ponowne tworzenie baz danych grup dostępności zoptymalizowanych pod kątem pamięci. W programach SQL Server 2016 (13.x) i SQL Server 2017 (14.x) tabele oparte na dyskach nie używają równoległych ponownych powtórzeń, jeśli baza danych w grupie dostępności jest również zoptymalizowana pod kątem pamięci.

Aby uzyskać więcej informacji, zobacz Always On - HADRON Learning Series: Worker Pool Usage for HADRON Enabled Databases (blog dla inżynierów programu SQL Server CSS).

Uprawnienia (instancja serwera)

Powiązane zadania (wystąpienie serwera)

Powiązana zawartość (instancja serwera)

• Always On — seria szkoleniowa HADRON: wykorzystanie puli roboczej dla baz danych z obsługą HADRON

Zalecenia dotyczące łączności sieciowej

Zdecydowanie zalecamy używanie tych samych łączy sieciowych do komunikacji między węzłami WSFC oraz do komunikacji między replikami dostępności. Użycie oddzielnych linków sieciowych może powodować nieoczekiwane zachowania, jeśli niektóre łącza kończą się niepowodzeniem (nawet sporadycznie).

Na przykład aby grupa dostępności obsługiwała automatyczne przełączanie awaryjne, replika pomocnicza będąca partnerem automatycznego przełączenia awaryjnego musi być w stanie ZSYNCHRONIZOWANYM. Jeśli połączenie sieciowe z tą repliką pomocniczą zakończy się niepowodzeniem (nawet sporadycznie), replika przechodzi w stan UNSYNCHRONIZED i nie może rozpocząć ponownej synchronizacji, dopóki łącze nie zostanie przywrócone. Jeśli WSFC żąda automatycznego przełączenia, gdy replika pomocnicza jest niezsynchronizowana, automatyczne przełączenie nie nastąpi.

Obsługa łączności klienta

Aby uzyskać informacje o obsłudze zawsze włączonych grup dostępności dla łączności klienta, zobacz Sterownik i obsługa łączności klienta dla grup dostępności.

Wymagania wstępne i ograniczenia dotyczące używania wystąpienia klastra trybu failover programu SQL Server do hostowania repliki dostępności

W tej sekcji:

• ograniczenia
• lista kontrolna : wymagania wstępne
• powiązane zadania
• Powiązana Zawartość

Ograniczenia (FCI)

• Węzły klastra FCI mogą hostować tylko jedną replikę dla danej grupy dostępności: Jeśli dodasz replikę dostępności do FCI, węzły WSFC, które mogą być właścicielami FCI, nie mogą hostować innej repliki dla tej samej grupy dostępności. Aby uniknąć możliwych konfliktów, zaleca się określenie możliwych właścicieli instancji klastra trybu failover. Uniemożliwia to sytuację, w której pojedyncze WSFC próbuje hostować dwie replikacje dostępności dla tej samej grupy dostępności.

  Ponadto każda inna replika musi być hostowana przez wystąpienie programu SQL Server, które znajduje się w innym węźle klastra w tym samym klastrze trybu failover systemu Windows Server. Jedynym wyjątkiem jest to, że podczas migracji do innego klastra, grupa dostępności może tymczasowo być częścią dwóch klastrów.

  Ostrzeżenie

  Użycie Menedżera klastra trybu failover do przeniesienia klastra trybu failover hostujących grupę dostępności do węzła, który jest już hostowanie repliki tej samej grupy dostępności może spowodować utratę repliki grupy dostępności, uniemożliwiając jej przełączenie w tryb online w węźle docelowym. Jeden węzeł klastra trybu failover nie może hostować więcej niż jednej repliki dla tej samej grupy dostępności. Aby uzyskać więcej informacji na temat tego, jak to się stanie i jak odzyskać, zobacz blog Replica nieoczekiwanie porzucony w grupie dostępności.

• wystąpienia klastrów trybu failover nie obsługują automatycznego trybu failover przez grupy dostępności: wystąpienia klastrów trybu failover nie obsługują automatycznego trybu failover przez grupy dostępności, więc każda replika dostępności hostowana przez wystąpienie klastra trybu failover może być skonfigurowana tylko do ręcznego przejścia w tryb failover.

• pl-PL: zmiana nazwy sieci instancji klastra przełączania awaryjnego: Jeśli musisz zmienić nazwę sieci instancji klastra przełączania awaryjnego hostującej replikę dostępności, należy usunąć replikę z jej grupy dostępności, a następnie dodać replikę z powrotem do grupy dostępności. Nie można usunąć repliki podstawowej, więc jeśli zmieniasz nazwę wystąpienia klastra trybu failover hostujące replikę podstawową, należy przewrócić w tryb failover do repliki pomocniczej, a następnie usunąć poprzednią replikę podstawową i dodać ją z powrotem. Zmiana nazwy klastra awaryjnego (FCI) może zmienić adres URL jego punktu końcowego replikacji bazy danych. Po dodaniu repliki upewnij się, że określono bieżący adres URL punktu końcowego.

Lista kontrolna: wymagania wstępne (FCI)

Powiązane zadania (FCI)

Powiązana zawartość (FCI)

• Klastrowanie awaryjne i Always On Availability Groups (SQL Server)

• Przewodnik po architekturze Always On: tworzenie rozwiązania o wysokiej dostępności i odzyskiwania po awarii przy użyciu instancji klastra failover i grup dostępności

Wymagania wstępne i ograniczenia grupy dostępności

W tej sekcji:

• Ograniczenia
• Wymagania
• Bezpieczeństwo
• powiązane zadania

Ograniczenia (grupy dostępności)

• pl-PL: Repliki dostępności muszą być hostowane przez różne węzły jednego WSFC: Dla danej grupy dostępności repliki dostępności muszą być hostowane przez wystąpienia serwera uruchomione na różnych węzłach tego samego WSFC. Jedynym wyjątkiem jest to, że podczas migracji do innego klastra grupa dostępności może tymczasowo obejmować dwa klastry.

  Notatka

  Maszyny wirtualne na tym samym komputerze fizycznym mogą hostować replikę dostępności dla tej samej grupy dostępności, ponieważ każda maszyna wirtualna działa jako oddzielny komputer.

• Unikatowa nazwa grupy dostępności: Każda nazwa grupy dostępności musi być unikatowa w usłudze WSFC. Maksymalna długość nazwy grupy dostępności to 128 znaków.

• Repliki dostępności: Każda grupa dostępności obsługuje jedną replikę podstawową i maksymalnie osiem replik pomocniczych. Wszystkie repliki mogą działać w trybie zatwierdzania asynchronicznego, lub maksymalnie pięć z nich można uruchamiać w trybie zatwierdzania synchronicznego (jedna replika podstawowa z dwiema synchronicznymi replikami pomocniczymi). Każda replika musi mieć unikatową nazwę serwera w systemach Windows i SQL Server. Nazwy serwerów między systemami Windows i SQL Server muszą być zgodne.

• Maksymalna liczba grup dostępności i baz danych dostępności na komputer: Rzeczywista liczba baz danych i grup dostępności, które można umieścić na komputerze (maszynie wirtualnej lub fizycznej) zależy od sprzętu i obciążenia, ale nie ma wymuszonego limitu. Firma Microsoft przetestowała maksymalnie 10 grup AG i 100 baz danych na maszynę fizyczną, jednak nie jest to wiążący limit. W zależności od specyfikacji sprzętu na serwerze i obciążeniu można umieścić większą liczbę baz danych i grup dostępności w wystąpieniu programu SQL Server. Oznaki przeciążonych systemów mogą obejmować, ale nie są ograniczone do wyczerpania wątków roboczych, wydłużonego czasu reakcji dla widoków systemowych grupy dostępności i widoków DMV oraz/lub wstrzymanych zrzutów systemu dyspozytora. Upewnij się, że dokładnie przetestuj środowisko przy użyciu obciążenia przypominającego środowisko produkcyjne, aby upewnić się, że może obsłużyć szczytową pojemność obciążenia w ramach umów SLA aplikacji. Podczas rozważania umów SLA należy wziąć pod uwagę obciążenie w warunkach awarii, a także oczekiwane czasy odpowiedzi.

• Nie używaj Menedżera klastra pracy awaryjnej do zarządzania grupami dostępności. Stan klastra FCI SQL Server jest współużytkowany między programem SQL Server a klastrem trybu failover systemu Windows Server (WSFC). Program SQL Server utrzymuje bardziej szczegółowe informacje o stanie instancji, niż jest to istotne dla klastra. Model zarządzania polega na tym, że program SQL Server musi napędzać transakcje i jest odpowiedzialny za utrzymywanie widoku stanu klastra w synchronizacji z widokiem stanu programu SQL Server. Jeśli stan klastra zostanie zmieniony poza programem SQL Server, możliwe jest, aby stan mógł wyjść z synchronizacji między usługami WSFC i SQL Server, co może prowadzić do nieprzewidywalnego zachowania.

  Na przykład:

  • Nie zmieniaj żadnych właściwości grupy dostępności, takie jak możliwi właściciele.

  • Nie używaj Menedżera klastra trybu failover do przełączania grup dostępności. Należy użyć Transact-SQL lub SQL Server Management Studio.

• Nie dodawaj zasobów ani nie zmieniaj zależności skojarzonych z rolą grupy dostępności. Nie zalecamy umieszczania żadnych dodatkowych zasobów (w tym użytkowników lub innych firm) w roli grupy dostępności ani zmiany zależności ról, ponieważ te zmiany mogą negatywnie wpłynąć na wydajność pracy w trybie failover.

Wymagania wstępne (grupy dostępności)

Podczas tworzenia lub ponownego konfigurowania konfiguracji grupy dostępności upewnij się, że są spełnione następujące wymagania.

Zabezpieczenia (grupy dostępności)

• Bezpieczeństwo jest dziedziczone z WSFC. Klaster trybu failover systemu Windows Server zapewnia dwa poziomy zabezpieczeń użytkownika na poziomie szczegółowości całego klastra:

  • Dostęp tylko do odczytu

  • Pełna kontrola

    Grupy dostępności Always On wymagają pełnej kontroli, a włączenie ich w wystąpieniu programu SQL Server zapewnia im pełną kontrolę nad klastrem (poprzez identyfikator SID usługi).

    Nie można bezpośrednio dodawać ani usuwać zabezpieczeń dla wystąpienia serwera w Menedżerze klastra. Aby zarządzać sesjami zabezpieczeń klastra, użyj menedżera konfiguracji programu SQL Server lub odpowiednika usługi WMI z programu SQL Server.

• Każde wystąpienie programu SQL Server musi mieć uprawnienia dostępu do rejestru, klastra itd.

• Zalecamy użycie szyfrowania dla połączeń między wystąpieniami serwera, które hostują repliki dostępności w grupach dostępności Always On.

Uprawnienia (grupy dostępności)

Powiązane zadania (grupy dostępności)

Wymagania wstępne i ograniczenia bazy danych dostępności

Aby kwalifikować się do dodania do grupy dostępności, baza danych musi spełniać następujące wymagania wstępne i ograniczenia.

W tej sekcji:

• Wymagania
• ograniczenia
• Zalecenia dotyczące komputerów hostujących repliki dostępności (system Windows
• Uprawnienia Dostępu
• powiązane zadania

Lista kontrolna: Wymagania (bazy danych dostępności)

Aby kwalifikować się do dodania do grupy dostępności, baza danych musi:

Ograniczenia (bazy danych dostępności)

• Jeśli ścieżka pliku (w tym litera dysku) pomocniczej bazy danych różni się od ścieżki odpowiedniej podstawowej bazy danych, obowiązują następujące ograniczenia:

  • Kreator nowej grupy dostępności/Kreator dodawania bazy danych do grupy dostępności: opcja pełna nie jest obsługiwana (na stronie Wybierz początkową synchronizację danych (Zawsze włączone kreatory grup dostępności) strony)

  • RESTORE WITH MOVE: Aby utworzyć pomocnicze bazy danych, pliki bazy danych muszą zostać PRZYWRÓCONE Z FUNKCJĄ MOVE w każdym wystąpieniu programu SQL Server, które hostuje replikę pomocniczą.

  • wpływ na operacje dodawania plików: późniejsza operacja dodawania pliku w repliki podstawowej może zakończyć się niepowodzeniem w pomocniczych bazach danych. Ten błąd może spowodować wstrzymanie pomocniczych baz danych. To z kolei powoduje, że repliki pomocnicze przechodzą w stan NOT SYNCHRONIZING.

    Notatka

    Aby uzyskać informacje na temat reagowania na nieudaną operację ad-file, zobacz Rozwiązywanie problemów z nieudaną operacją Add-File (Zawsze Włączone Grupy Dostępności).

• Nie można usunąć bazy danych, która obecnie należy do grupy dostępności.

Monitorowanie baz danych chronionych przez funkcję TDE

Jeśli używasz przezroczystego szyfrowania danych (TDE), certyfikat lub klucz asymetryczny do tworzenia i odszyfrowywania innych kluczy musi być taki sam w każdym wystąpieniu serwera, które hostuje replikę dostępności dla grupy dostępności. Aby uzyskać więcej informacji, zobacz Przenoszenie chronionej bazy danych TDE do innego programu SQL Server.

Uprawnienia (bazy danych dostępności)

Wymaga uprawnienia ALTER w bazie danych.

Powiązane zadania (bazy danych dostępności)

Powiązana zawartość

• przewodnik po rozwiązaniach Always On programu Microsoft SQL Server dotyczący wysokiej dostępności i odtwarzania po awarii
• Blog zespołu SQL Server Always On: oficjalny blog zespołu SQL Server Always On
• Always On — seria szkoleniowa HADRON: użycie puli roboczej dla baz danych obsługujących HADRON
• Co to jest Always On grupa dostępności?
• klaster trybu failover i zawsze włączone grupy dostępności (SQL Server)
• Obsługa łączności sterowników i klientów dla grup dostępności