Zawsze włączone grupy dostępności programu SQL Server to najnowsza technologia firmy Microsoft służąca zaspokajaniu potrzeb organizacji korzystających z programu SQL Server w zakresie wysokiej dostępności i odzyskiwania po awarii. Dużą zaletą AlwaysOn jest możliwość obsługi zarówno HA, jak i DR w jednej implementacji. Doświadczyliśmy następujących kluczowych korzyści z AlwaysOn:
Możemy zgrupować powiązane bazy danych w ramach jednej grupy dostępności i przełączyć je razem w tryb awaryjny na wypadek, gdyby było to potrzebne. Jest to szczególnie przydatne w przypadku aplikacji, które zależą od więcej niż jednej bazy danych, takich jak Microsoft Office SharePoint, Microsoft Lync i Sage.
W porównaniu z wystąpieniami klastra trybu failover programu SQL Server okazuje się, że pamięć jako pojedynczy punkt awarii została wyeliminowana, ponieważ każda instancja stanowi replikę ma przypisane własne miejsce do przechowywania.
Dzięki AlwaysOn możliwe jest jednoczesne skonfigurowanie HA i DR. Osiąga się to poprzez utworzenie klastrów Windows Failover z wieloma lokacjami jako podstawy konfiguracji AlwaysOn. Wykonywanie zmiany ról podczas korzystania z AlwaysOn jest znacznie prostsze niż w przypadku korzystania z przesyłania dziennika transakcji.
Obiekty komputerowe
Active Directory (AD) to ogromny temat i nie będziemy zagłębiać się w szczegóły w tym artykule. Jak można się domyślić, Active Directory to usługa katalogowa Microsoftu. W kategoriach sieci komputerowych usługa katalogowa to funkcja, która pozwala nam centralnie rejestrować, identyfikować i zarządzać wszystkimi obiektami w sieci. Wpisy w usługach katalogowych mapują nazwy urządzeń sieciowych na odpowiednie adresy IP i inne właściwości w katalogu. Najczęstszymi obiektami w usłudze katalogowej (i AD firmy Microsoft) są Użytkownicy i komputery. Tak jak każdy użytkownik w domenie może być zarejestrowany i zarządzany z Active Directory, tak każdy komputer w domenie może być zarządzany z Active Directory. Tak jak każdy użytkownik powinien mieć unikalne konto w Active Directory, tak samo jest z każdym komputerem.
W Active Directory nie wszystkie obiekty komputerowe są mapowane na fizyczny komputer. Obiekt komputerowy może reprezentować fizyczny komputer (stację roboczą lub serwer), ale może również reprezentować coś, co działa jak komputer, na przykład reprezentatywna nazwa klastra systemu Windows lub wirtualna nazwa usługi klastrowania (rola). Takie reprezentacje są również unikalne w Active Directory, podobnie jak zwykłe nazwy komputerów.
CNO i VNO w WSFC
Gdy instalujesz Windows Failover Cluster, instalator tworzy w Active Directory jednostkę o nazwie Computer Name Object (CNO). Ten CNO jest podstawową jednostką utworzoną w Active Directory dla klastra i reprezentuje „Nazwę serwera” całego klastra. Następnie inne obiekty znane jako Virtual Name Objects są tworzone przez CNO podczas wykonywania takich czynności, jak tworzenie ról w klastrach, grup dostępności, lub Odbiorniki grupy dostępności . Te CNO i VNO mają powiązane z nimi adresy IP. Możesz określić te adresy podczas instalowania klastra lub tworzenia nowej roli klastra lub odbiornika. Dla każdego tworzonego klastra, roli i odbiornika potrzebna jest unikatowa nazwa komputera i unikalny adres IP. Rys. 1 pokazuje krok, podczas którego określasz obiekt nazwy klastra i jego adres IP podczas konfigurowania klastra.
Nazwy używane podczas konfigurowania klastra są całkowicie dowolne. Po prostu muszą być wyjątkowe. Zaleca się jednak, aby podczas tworzenia CNO lub VNO przestrzegać konwencji nazewnictwa swojej organizacji dla zwykłych komputerów — ułatwia to zarządzanie. Sensowne jest również użycie określonego bloku adresów IP, który pokryje wszystkie potrzeby adresowania całego klastra – CNO i wszystkich VNO (role), które zamierzasz utworzyć.
Rys. 1 mapowanie nazwy na adres w klastrze
Kluczowe uprawnienia domeny
DBA lub administrator systemu przeprowadzający instalację klastra musi mieć uprawnienia do Tworzenia obiektów komputerowych w domenie Active Directory. Z kolei po utworzeniu obiektu nazwy komputera administrator domeny musi przyznać następujące uprawnienia obiektowi nazwy komputera, aby można było pomyślnie tworzyć role (w wyniku których powstają obiekty nazw wirtualnych) w klastrze:
Utwórz obiekty komputerowe
Przeczytaj wszystkie właściwości
Bez tych uprawnień prawdopodobnie otrzymasz komunikaty o błędach podobne do poniższego podczas próby utworzenia roli (w przypadku AlwaysOn FCI ) lub słuchacza (w przypadku AlwaysOn AG ):
Błąd podczas instalacji klastra MS SQL Server:
Zasób nazwy sieci klastra „SQL Network Name (EUK-SCCM-01)” nie mógł utworzyć powiązanego obiektu komputera w domenie „domainname.com” z następującego powodu:Nie można utworzyć konta komputera.
Tekst powiązanego kodu błędu to:Odmowa dostępu.
Ten komunikat o błędzie jest obserwowany w Podglądzie zdarzeń, ponieważ SQL Server nie byłby w tej chwili dostępny. Będziesz mógł to również zobaczyć, jeśli przejdziesz do plików dziennika błędów SQL w folderze LOG, który znajduje się w katalogu instalacyjnym SQL Server. Fraza kluczowa to „Odmowa dostępu ”.
Inne wymagania
Powinienem wspomnieć o koncepcji kontrolera domeny. Kontroler domeny, a dokładniej zestaw kontrolerów domeny, zapewnia kluczowe usługi dla Active Directory, takie jak rejestrowanie obiektów i uwierzytelnianie użytkowników i komputerów. Aby pomyślnie skonfigurować klaster lub odbiornik AlwaysOn Listener, kontroler domeny musi być dostępny z komputera, na którym przeprowadzasz konfigurację. Oznacza to, że komunikacja między komputerem a kontrolerem domeny musi być otwarta na wielu portach TCP i UDP. Microsoft dokumentuje to bardzo szczegółowo w tym artykule . Może to być dane w większości przypadków, ale przy rozwiązywaniu problemów z łącznością pomaga wiedzieć, co jest rzeczywiście potrzebne.
W poprzednim artykule , wspomniałem również, że konieczne jest przyznanie uprawnień CNO klastra podczas konfigurowania kworum udostępniania plików.
Rys. 2 Uprawnienia w udziale plików
Uwaga na temat rozpoznawania nazw
Będąc obiektami komputerowymi, CNO i VNO zależą od usługi nazw domen, aby rozpoznać nazwę wskazaną podczas instalowania klastra, tworzenia roli lub tworzenia nasłuchiwania AlwaysOn. Zazwyczaj klienci otrzymują te nazwy komputerów w celu nawiązania połączenia z klastrem. Innymi słowy, adres IP jest dla nich przezroczysty, dzięki czemu konfiguracja klienta jest prosta i abstrahuje od przełączania awaryjnego od użytkowników końcowych.
Rys. 3 właściwości AG Listener dla Listenera z dwoma adresami IP
W poprzednim artykule wspomniałem o przypadku, w którym ten scenariusz może powodować problemy. W naszym klastrze z wieloma lokalizacjami mieliśmy jednego odbiornika dla naszej grupy AlwaysOn Availability Group. Ten odbiornik został skonfigurowany do rozpoznawania dwóch adresów IP. Jest to konieczne w przypadku klastra z wieloma lokacjami obejmującego wiele podsieci. W takiej konfiguracji serwer nazw zwróci oba adresy IP zmapowane na słuchacza po wydaniu nslookup sprawdź (patrz rys. 4). Jednak podczas łączenia możesz uzyskać dostęp tylko do jednego z tych adresów IP naraz. Menedżer klastra pokaże drugi adres IP jako Offline (patrz rys. 5).
Rys. 4 właściwości odbiornika AG dla odbiornika z dwoma adresami IP
Rys. 5 właściwości roli klastra z dwoma adresami IP w osobnych podsieciach
To normalne. W przypadku przełączenia awaryjnego do lokacji alternatywnej serwer DNS po kilku minutach rozpoczyna rozpoznawanie alternatywnego adresu IP. Konsekwencją tego jest to, że komunikacja klientów z alternatywną lokalizacją musi być możliwa. Rys. 6 i Rys. 7 podkreślają to jeszcze bardziej.
Rys. 6 Ścieżka komunikacji z repliką podstawową w Dakarze
Przyjrzyjmy się dobrze ścieżce, którą pakiety przejdą z komputerów klienckich do klastra. Gdy replika podstawowa znajduje się w Dakarze, nazwa odbiornika SQL-SVR-LNR jest tłumaczona na adres IP 192.168.1.20, a WFCS z kolei kieruje żądanie do serwera 192.168.1.22 (należy zauważyć, że ten serwer również ma swój własny Nazwa komputera). W przypadku przełączenia awaryjnego do Nairobi mamy ścieżkę komunikacyjną przechodzącą przez 192.168.2.20, a następnie 192.168.2.22. Implikacja jest taka, że aby zapewnić bezproblemową obsługę klienta, wszyscy klienci we wszystkich centrach danych muszą mieć dozwoloną komunikację na wszystkich zaangażowanych firewallach korzystających z portu 1433.
Rys. 7 Ścieżka komunikacji z repliką podstawową w Nairobi
Wniosek
Chociaż Windows Failover Clustering, Active Directory i Domain Name Service mogą być poza rolą administratora bazy danych, opłaca się mieć podstawową wiedzę na temat działania tych technologii, aby móc budować i rozwiązywać problemy z AlwaysOn Wystąpienia klastrów pracy awaryjnej i grupy dostępności AlwaysOn. Niektóre organizacje mają ścisły rozdział obowiązków między administratorami systemu i administratorami baz danych, ale tam, gdzie tak nie jest, administrator bazy danych musi być w stanie ogarnąć te koncepcje systemu Windows, aby odnieść sukces jako administrator bazy danych.
Odniesienia
Przegląd zawsze włączonych grup dostępności
Klaster pracy awaryjnej Windows z SQL Server
Omówienie usług i wymagania dotyczące portów sieciowych dla systemu Windows
Administrowanie obiektami komputerowymi
