Synchronized Logins

Synchronized Logins to zgodne konta logowania utrzymywane między serwerem podstawowym a repliką w grupie dostępności.

Na czym polega zgodność loginów w grupie dostępności

Synchronized Logins to określenie używane w kontekście programu Microsoft SQL Server i grup dostępności Always On Availability Groups. Login jest obiektem na poziomie instancji SQL Server, a nie elementem pojedynczej bazy danych. Przechowuje między innymi nazwę podmiotu uwierzytelniającego, typ logowania, identyfikator SID oraz — w przypadku logowania SQL Server — informacje potrzebne do weryfikacji hasła. Grupa dostępności może utrzymywać kopie baz danych na kilku replikach, ale nie replikuje automatycznie wszystkich obiektów znajdujących się na poziomie instancji.

Z tego powodu login utworzony na serwerze podstawowym może nie istnieć na serwerze pomocniczym albo może mieć inny identyfikator SID. Sama zgodność tekstowej nazwy loginu nie wystarcza. Użytkownik bazy danych jest powiązany z loginem za pomocą identyfikatora SID. Jeżeli po przełączeniu grupy dostępności na inną replikę login zostanie utworzony z tym samym imieniem, lecz z innym SID-em, konto może nie zostać prawidłowo rozpoznane jako podmiot przypisany do istniejącego użytkownika bazy.

SID, użytkownik bazy i problem osieroconego dostępu

W relacyjnej bazie danych SQL Server należy rozróżnić login serwerowy od użytkownika bazy danych. Login służy do uwierzytelnienia na instancji, natomiast użytkownik określa uprawnienia wewnątrz konkretnej bazy. Relacja między tymi obiektami jest oparta na SID. Gdy baza zostaje przeniesiona lub udostępniona na innej replice, użytkownik zapisany w bazie nadal ma swój pierwotny SID, lecz na replice może brakować odpowiadającego loginu. Taki stan jest często określany jako osierocony użytkownik.

Skutkiem może być nieudane logowanie do aplikacji po przełączeniu ról albo brak dostępu do bazy mimo istnienia konta o tej samej nazwie. Dotyczy to szczególnie logowań SQL Server, ponieważ ich definicje i skróty haseł są przechowywane na poziomie instancji. Logowania Windows lub grupy Windows również muszą być dostępne w odpowiednim środowisku, a ich uprawnienia w bazie powinny wskazywać właściwe podmioty. Zgodność loginów oznacza więc nie tylko powtarzalność nazw, lecz także zachowanie właściwych SID-ów, typów kont i ustawień wymaganych przez konkretną konfigurację.

Przygotowanie loginów na replice pomocniczej

Przed użyciem repliki jako serwera podstawowego należy utworzyć na niej odpowiednie loginy serwerowe. W przypadku logowania SQL Server trzeba zachować ten sam SID oraz skonfigurować konto w sposób zgodny z loginem na dotychczasowym serwerze podstawowym, w tym z odpowiednim hasłem. Samo wykonanie polecenia tworzącego login z nazwą i nowym hasłem może doprowadzić do rozbieżności. W praktyce administrator przygotowuje skrypt odtwarzający loginy i ich właściwości, a następnie uruchamia go na każdej replice, która może przejąć rolę podstawową.

Weryfikacja powinna obejmować między innymi obecność loginu na wszystkich replikach, zgodność SID-u, status konta, domyślną bazę oraz członkostwo w stałych lub zdefiniowanych przez administratora rolach serwerowych. Należy także sprawdzić użytkowników i role w samej bazie, ponieważ poprawny login nie nadaje automatycznie uprawnień do danych. Przydatne jest wykonanie kontrolnego przełączenia grupy dostępności w zaplanowanym oknie oraz sprawdzenie logowania aplikacji i użytkowników po zmianie roli. Test powinien obejmować zarówno uwierzytelnianie Windows, jak i logowania SQL Server, jeśli oba mechanizmy są używane.

W niektórych konfiguracjach można korzystać z użytkowników zawartych w bazie danych, czyli contained database users. Taki użytkownik przechowuje dane potrzebne do uwierzytelnienia w bazie, a nie wyłącznie w katalogu logowań instancji. Nie oznacza to jednak, że każdy problem z dostępem w grupie dostępności znika automatycznie. Nadal trzeba zweryfikować konfigurację aplikacji, uprawnienia, zasady uwierzytelniania oraz zgodność rozwiązania z używaną wersją i ustawieniami SQL Server. Dla zwykłych loginów serwerowych synchronizacja pozostaje osobnym zadaniem administracyjnym.

Znaczenie zgodnych loginów po przełączeniu ról

Podczas normalnej pracy aplikacja może łączyć się z aktualną repliką podstawową przez nazwę odbiornika grupy dostępności, czyli skonfigurowany punkt połączenia kierujący ruch do właściwej repliki. Po przełączeniu ról ten sam punkt może wskazywać inną instancję. Bazy danych są wtedy dostępne na nowym serwerze podstawowym, lecz żądanie logowania nadal jest obsługiwane przez jego lokalną konfigurację instancji. Jeżeli login nie został wcześniej odtworzony albo ma niezgodny SID, aplikacja może zgłaszać błąd uwierzytelniania, mimo że sama baza działa i została prawidłowo zsynchronizowana.

Diagnoza takiego przypadku powinna rozdzielić trzy etapy: dotarcie połączenia do właściwego odbiornika, uwierzytelnienie loginu na instancji oraz mapowanie loginu na użytkownika w bazie. Informacja o braku dostępu do obiektu nie zawsze oznacza brak loginu, a błąd logowania nie musi wskazywać na uszkodzenie replikacji danych. Należy porównać stan loginów na replikach, przeanalizować komunikat SQL Server i sprawdzić, czy użytkownik bazy wskazuje ten sam SID, który ma login na aktualnym serwerze podstawowym. Takie rozdzielenie pozwala odróżnić problem konfiguracji kont od problemu samej grupy dostępności.