Klaster trybu failover i zawsze włączone grupy dostępności (SQL Server)
Dotyczy:programu SQL Server — tylko system Windows
Grupy dostępności Always On, rozwiązanie zapewniające wysoką dostępność oraz odzyskiwanie po awarii, wprowadzone w programie SQL Server 2012 (11.x), wymagają usługi Windows Server Failover Clustering (WSFC). Ponadto, mimo że grupy dostępności Always On nie są zależne od klastrowania trybu failover w SQL Server, można użyć wystąpienia klastra trybu failover (FCI) do hostowania repliki dostępności dla grupy dostępności. Ważne jest, aby znać rolę każdej technologii klastrowania i wiedzieć, jakie zagadnienia są niezbędne podczas projektowania środowiska zawsze włączonych grup dostępności.
Notatka
Aby uzyskać informacje o pojęciach dotyczących zawsze włączonych grup dostępności, zobacz Omówienie zawsze włączonych grup dostępności (SQL Server).
Klaster trybu failover systemu Windows Server i grupy dostępności
Wdrażanie grup dostępności Always On wymaga klastra failover systemu Windows Server (WSFC). Aby można było włączyć dla Grup dostępności Always On, wystąpienie programu SQL Server musi znajdować się w węźle WSFC, a węzeł WSFC musi być online. Ponadto każda replika dostępności w obrębie danej grupy dostępności musi znajdować się w innym węźle tego samego klastra WSFC. Jedynym wyjątkiem jest to, że podczas migracji do innego klastra WSFC, grupa dostępności może tymczasowo znajdować się w dwóch klastrach jednocześnie.
Grupy dostępności Always On opierają się na klastrze przełączania awaryjnego systemu Windows Server (WSFC), aby monitorować i zarządzać bieżącymi rolami replik dostępności należących do danej grupy dostępności oraz określać, jak zdarzenie przełączenia awaryjnego wpływa na repliki dostępności. Grupa zasobów WSFC jest tworzona dla każdej utworzonej grupy dostępności. WSFC monitoruje tę grupę zasobów w celu oceny kondycji repliki podstawowej.
Kworum dla grup dostępności Always On opiera się na wszystkich węzłach klastra WSFC, niezależnie od tego, czy dany węzeł klastra hostuje jakiekolwiek repliki dostępności. W przeciwieństwie do dublowania bazy danych, w Always On grupach dostępności nie ma roli świadka.
Ogólna kondycja usługi WSFC jest określana przez liczbę głosów kworum węzłów w klastrze. Jeśli WSFC przejdzie w tryb offline z powodu nieplanowanej awarii lub z powodu trwałej awarii sprzętu lub komunikacji, wymagana jest ręczna interwencja administracyjna. Administrator systemu Windows Server lub WSFC będzie musiał wymusić kworum, a następnie przywrócić zachowane węzły klastra do trybu online w konfiguracji nieodpornej na błędy.
Ważny
Klucze rejestru grup dostępności Always On są podkluczami WSFC. Jeśli usuniesz i ponownie utworzysz usługę WSFC, musisz wyłączyć i ponownie włączyć funkcję Zawsze włączone grupy dostępności w każdym wystąpieniu programu SQL Server, które hostuje replikę dostępności w oryginalnym programie WSFC.
Jeśli chcesz uzyskać informacje na temat uruchamiania programu SQL Server w węzłach WSFC oraz kworum WSFC, zobacz klastrowanie trybu failover Windows Server (WSFC) z programem SQL Server.
Wystąpienia klastra Failover programu SQL Server (FCI) i Grupy Dostępności
Drugą warstwę przełączania awaryjnego można skonfigurować na poziomie instancji serwera, implementując SQL Server oraz instancję klastra przełączania awaryjnego razem z usługą WSFC. Replika dostępności może być hostowana przez autonomiczne wystąpienie programu SQL Server lub wystąpienie klastra trybu failover. Tylko jeden partner FCI może hostować replikę dla określonej grupy dostępności. Gdy replika dostępności działa na instancji klastra przełączania awaryjnego (FCI), lista możliwych właścicieli grupy dostępności będzie zawierać tylko aktywny węzeł FCI.
Grupy dostępności Always On nie zależą od żadnej formy magazynu udostępnionego. Jeśli jednak używasz instancji klastra trybu failover programu SQL Server do hostowania jednej lub więcej replik dostępności, każda z tych instancji będzie wymagała wspólnej pamięci masowej zgodnie ze standardową instalacją instancji klastra trybu failover programu SQL Server.
Aby uzyskać więcej informacji na temat dodatkowych wymagań wstępnych, zobacz sekcję "Wymagania wstępne i ograniczenia dotyczące używania wystąpienia klastra trybu failover programu SQL Server do hostowania repliki dostępności" w sekcji wymagania wstępne, ograniczenia i zalecenia dotyczące zawsze włączonych grup dostępności (SQL Server).
Porównanie wystąpień klastra trybu failover i grup dostępności
Niezależnie od liczby węzłów w klastrze trybu failover, całe wystąpienie tego klastra zawiera pojedynczą replikę w grupie dostępności. W poniższej tabeli opisano różnice w pojęciach między węzłami w klastrze trybu failover i replikami w grupie dostępności.
Węzły w ramach klastra z funkcją przełączania awaryjnego (FCI) | Repliki w grupie dostępności | |
---|---|---|
używa WSFC | Tak | Tak |
poziom ochrony | Instancja | Baza danych |
typ magazynu | Udostępnione | Nieudostępniane Chociaż repliki w grupie dostępności nie współdzielą zasobów magazynowych, replika obsługiwana przez klaster trybu failover korzysta ze współdzielonego rozwiązania magazynowania zgodnie z wymaganiami tego klastra. Rozwiązanie magazynowe jest współużytkowane tylko przez węzły w ramach wystąpienia klastrowego trybu failover (FCI) i nie jest współdzielone między replikami grupy dostępności. |
rozwiązania Storage | Bezpośrednie dołączanie, sieć SAN, punkty instalacji, SMB | Zależy od typu węzła |
Drugorzędne z możliwością odczytu | Nie* | Tak |
odpowiednie ustawienia zasad trybu przełączania awaryjnego | Kworum WSFC Specyficzne dla wystąpienia FCI Ustawienia grupy dostępności** |
Kworum WSFC Ustawienia grupy dostępności |
Przełączone zasoby awaryjne | Serwer, wystąpienie i baza danych | Tylko baza danych |
pl-PL: *Podczas gdy synchroniczne repliki pomocnicze w grupie dostępności są zawsze uruchomione na swoich odpowiednich wystąpieniach programu SQL Server, węzły pomocnicze w FCI (instancji klastra trybu failover) faktycznie nie mają uruchomionych swoich wystąpień programu SQL Server i dlatego nie można na nich odczytać danych. W przypadku klastra trybu failover (FCI), węzeł pomocniczy uruchamia swoje wystąpienie programu SQL Server tylko wtedy, gdy własność grupy zasobów zostanie do niego przeniesiona podczas przełączenia awaryjnego FCI. Jednak na aktywnym węźle FCI, gdy baza danych hostowana przez FCI należy do grupy dostępności, jeśli lokalna replika dostępności pracuje jako replika pomocnicza do odczytu, baza danych jest dostępna do odczytu.
Ustawienia zasad trybu failover dla grupy dostępności mają zastosowanie do wszystkich replik, niezależnie od tego, czy są hostowane w wystąpieniu autonomicznym, czy w instancji klastra trybu failover.
Notatka
Aby uzyskać więcej informacji na temat liczby węzłów w ramach instancji klastra trybu failover (FCI) i grupy dostępności Always On dla różnych edycji programu SQL Server, zobacz Funkcje obsługiwane przez edycje programu SQL Server 2012 (https://go.microsoft.com/fwlink/?linkid=232473).
Rozważania dotyczące hostowania repliki dostępności w klastrze awaryjnego przełączania (FCI)
Ważny
Jeśli planujesz hostować replikę dostępności w wystąpieniu klastra trybu failover programu SQL Server (FCI), upewnij się, że węzły hosta systemu Windows Server 2008 spełniają wymagania wstępne i ograniczenia dotyczące wystąpień klastra trybu failover (FCI). Aby uzyskać więcej informacji, zobacz Wymagania wstępne, Ograniczenia i Zalecenia dotyczące Always On Availability Groups (SQL Server).
Wystąpienia klastra trybu awaryjnego SQL Server (FCI) nie obsługują automatycznego przejścia w tryb awaryjny przez grupy dostępności, więc każda replika dostępności hostowana przez FCI może być skonfigurowana tylko do ręcznego przejścia w tryb awaryjny.
Może być konieczne skonfigurowanie usługi WSFC w celu uwzględnienia dysków udostępnionych, które nie są dostępne we wszystkich węzłach. Rozważmy na przykład usługę WSFC w dwóch centrach danych z trzema węzłami. Dwa węzły hostują instancję switchover klastra SQL Server (FCI) w centrum danych podstawowym i mają dostęp do tych samych współdzielonych dysków. Trzeci węzeł obsługuje autonomiczne wystąpienie programu SQL Server w innym centrum danych i nie ma dostępu do współdzielonych dysków z podstawowego centrum danych. Ta konfiguracja usługi WSFC obsługuje wdrażanie grupy dostępności, jeśli FCI hostuje replikę podstawową, a wystąpienie autonomiczne hostuje replikę pomocniczą.
Podczas wybierania FCI do hostowania repliki dostępności dla danej grupy dostępności upewnij się, że przełączenie awaryjne FCI nie może spowodować, że pojedynczy węzeł WSFC spróbuje hostować dwie repliki dostępności dla tej samej grupy dostępności.
Poniższy przykładowy scenariusz ilustruje, jak ta konfiguracja może prowadzić do problemów:
Konfigurujesz klaster WSFC z dwoma węzłami: NODE01
i NODE02
. Instalujesz wystąpienie klastra trybu failover programu SQL Server, fciInstance1
na obydwu NODE01
i NODE02
, gdzie NODE01
jest bieżącym właścicielem dla fciInstance1
.
W NODE02
zainstalujesz kolejne wystąpienie programu SQL Server, Instance3
, które jest samodzielnym wystąpieniem.
Na NODE01
włączasz fciInstance1 dla grup dostępności Always On. Na NODE02
włączasz Instance3
dla grup dostępności Always On. Następnie należy skonfigurować grupę dostępności, dla której fciInstance1
hostuje replikę podstawową, a Instance3
hostuje replikę pomocniczą.
W pewnym momencie fciInstance1
staje się niedostępny na NODE01
, a WSFC powoduje failover fciInstance1
do NODE02
. Po przejściu w tryb failover fciInstance1
jest instancją Always On grupy dostępności pełniącą rolę podstawową na NODE02
. Jednak Instance3
teraz znajduje się w tym samym węźle WSFC co fciInstance1
. Narusza to ograniczenie grup dostępności Always On.
Aby rozwiązać problem przedstawiony w tym scenariuszu, wystąpienie autonomiczne, Instance3
, musi znajdować się w innym węźle w tym samym WSFC co NODE01
i NODE02
.
Aby uzyskać więcej informacji o instancjach klastrów trybu przełączania awaryjnego (Always On Failover Cluster Instances) programu SQL Server, zobacz .
Ograniczenia dotyczące używania WSFC Menedżera klastra przełączania awaryjnego z grupami dostępności
Nie używaj Menedżera klastra Failover do manipulowania grupami dostępności, na przykład:
Nie dodawaj ani nie usuwaj zasobów w klastrowanej usłudze (grupie zasobów) dla grupy dostępności.
Nie zmieniaj żadnych właściwości grupy dostępności, takich jak możliwi i preferowani właściciele. Te właściwości są ustawiane automatycznie przez grupę dostępności.
Nie należy używać Menedżera klastra trybu failover do przenoszenia grup dostępności do różnych węzłów lub do przełączania grup dostępności w tryb failover. Menedżer klastra trybu failover nie zna stanu synchronizacji replik dostępności i może to prowadzić do wydłużenia przestoju. Należy użyć Transact-SQL lub SQL Server Management Studio.
Ostrzeżenie
Przeniesienie wystąpienia klastra trybu failover trybu failover hostowanie grupy 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. Pojedynczy węzeł klastra typu failover nie może hostować więcej niż jednej kopii zapasowej dla tej samej grupy dostępności. Aby uzyskać więcej informacji na temat tego, jak to się dzieje i jak przywrócić dostępność, zapoznaj się z wpisem na blogu Replica nieoczekiwanie usunięta w grupie dostępności.
Powiązana zawartość
Blogi :
Blog Zespołu SQL Server Always On: Oficjalny Blog Zespołu SQL Server Always On
Blogi
inżynierów programu SQL Server CSS oficjalny dokument :
przewodnik po architekturze zawsze włączonej : tworzenie rozwiązania wysokiej dostępności i odzyskiwania po awarii przy użyciu wystąpień klastra trybu failover i grup dostępności
oficjalne dokumenty firmy Microsoft dotyczące programu SQL Server 2012
Oficjalny dokument zespołu doradczego ds. sql Server
Zobacz też
omówienie zawsze włączonych grup dostępności (SQL Server)
włączanie i wyłączanie zawsze włączonych grup dostępności (SQL Server)
Monitorowanie grup dostępności (Transact-SQL)
Instancje klastra Always On Failover (SQL Server)