Eksplorowanie opcji wysokiej dostępności i odzyskiwania po awarii
Aby zaawizować rozwiązanie dla maszyn wirtualnych, należy najpierw poznać opcje dostępności wdrożeń opartych na usłudze IaaS.
Infrastruktura jako usługa a platforma jako usługa
Jeśli chodzi o dostępność, wybór rozwiązania IaaS lub PaaS ma znaczenie. W przypadku usługi IaaS masz maszynę wirtualną, co oznacza, że istnieje system operacyjny z instalacją programu SQL Server. Administrator lub grupa odpowiedzialna za program SQL Server będzie mieć wybór rozwiązań wysokiej dostępności i odzyskiwania po awarii (HADR) oraz dużej kontroli nad tym, jak to rozwiązanie zostało skonfigurowane.
W przypadku wdrożeń opartych na usłudze PaaS, takich jak usługa Azure SQL Database, rozwiązania HADR są wbudowane w tę funkcję i często muszą być włączone. Istnieją minimalne opcje, które można skonfigurować.
Ze względu na te różnice wybór rozwiązania IaaS lub PaaS może mieć wpływ na ostateczny projekt rozwiązania HADR.
Funkcje HADR programu SQL Server dla maszyny wirtualnej platformy Azure
W przypadku korzystania z usługi IaaS możesz użyć funkcji udostępnianych przez program SQL Server, aby zwiększyć dostępność. W niektórych przypadkach można połączyć je z funkcjami na poziomie platformy Azure, aby jeszcze bardziej zwiększyć dostępność.
Funkcje dostępne w programie SQL Server przedstawiono w poniższej tabeli
| Nazwa funkcji | Chroni |
|---|---|
| Zawsze włączone wystąpienie klastra trybu failover (FCI) | Wystąpienie |
| Zawsze włączona grupa dostępności | baza danych |
| Wysyłanie dziennika | baza danych |
Wystąpienie programu SQL Server to cała instalacja programu SQL Server (pliki binarne, wszystkie obiekty w wystąpieniu, takie jak identyfikatory logowania, zadania agenta programu SQL Server i bazy danych). Ochrona na poziomie wystąpienia oznacza, że całe wystąpienie jest uwzględniane w funkcji dostępności.
Baza danych w programie SQL Server zawiera dane używane przez użytkowników końcowych i aplikacje. Istnieją systemowe bazy danych, na których opiera się program SQL Server, a także bazy danych utworzone do użytku przez użytkowników końcowych i aplikacje. Wystąpienie programu SQL Server zawsze ma własne systemowe bazy danych. Ochrona na poziomie bazy danych oznacza, że wszystkie elementy, które są w bazie danych lub są przechwytywane w dzienniku transakcji dla użytkownika lub bazy danych aplikacji, są uwzględniane jako część funkcji dostępności. Wszystkie elementy, które istnieją poza bazą danych lub które nie są przechwytywane w ramach dziennika transakcji, takiego jak zadania agenta programu SQL Server i połączone serwery, muszą być obsługiwane ręcznie, aby upewnić się, że serwer docelowy może działać jak podstawowy, jeśli istnieje planowane lub nieplanowane zdarzenie trybu failover.
Zarówno wystąpienia klastra trybu failover, jak i grupy Zabezpieczeń wymagają podstawowego mechanizmu klastra. W przypadku wdrożeń programu SQL Server działających w systemie Windows Server jest to klaster trybu failover systemu Windows Server (WSFC), a dla systemu Linux jest to Pacemaker.
Zawsze włączone wystąpienia klastra trybu failover
Wystąpienie klastra trybu failover jest konfigurowane podczas instalowania programu SQL Server. Nie można przekonwertować autonomicznego wystąpienia programu SQL Server na wystąpienie klastra trybu failover. Wystąpienie klastra trybu failover ma przypisaną unikatową nazwę, a także adres IP, który różni się od serwerów bazowych lub węzłów uczestniczących w klastrze. Nazwa i adres IP muszą również różnić się od podstawowego mechanizmu klastra. Aplikacje i użytkownicy końcowi będą używać unikatowej nazwy wystąpienia klastra trybu failover na potrzeby dostępu. Ta abstrakcja umożliwia aplikacjom, aby nie musiały wiedzieć, gdzie jest uruchomione wystąpienie. Jedną z głównych różnic między wystąpieniami klastrów trybu failover opartymi na platformie Azure a lokalnymi wystąpieniami klastrów trybu failover jest to, że w przypadku platformy Azure wymagany jest wewnętrzny moduł równoważenia obciążenia (ILB). Moduł równoważenia obciążenia służy do zapewnienia, że aplikacje i użytkownicy końcowi mogą łączyć się z unikatową nazwą wystąpienia klastra trybu failover.
Gdy wystąpienie klastra trybu failover przełączy się w tryb failover do innego węzła, niezależnie od tego, czy jest inicjowane ręcznie, czy z powodu problemu, całe wystąpienie zostanie uruchomione ponownie w innym węźle. Oznacza to, że proces trybu failover jest pełnym zatrzymaniem i uruchomieniem programu SQL Server. Wszystkie aplikacje lub użytkownicy końcowi połączeni z klastrem trybu failover zostaną rozłączone podczas pracy w trybie failover, a tylko aplikacje, które mogą obsługiwać i odzyskiwać dane po tej przerwie, mogą zostać automatycznie ponownie połączone.
Po uruchomieniu na innym węźle wystąpienie przechodzi przez proces odzyskiwania. Wystąpienia klastra trybu failover będą spójne z punktem awarii, więc technicznie nie będzie utraty danych, ale wszystkie transakcje, które muszą zostać wycofane, zrobią to w ramach odzyskiwania. Jak wspomniano powyżej, ponieważ jest to ochrona na poziomie wystąpienia, wszystko, co konieczne (identyfikatory logowania, zadania agenta programu SQL Server itp.), jest już dostępne, aby firma mogła kontynuować działanie tak jak zwykle, gdy bazy danych będą gotowe.
Wystąpienia klastrów trybu failover wymagają jednej kopii bazy danych, ale jest to również pojedynczy punkt awarii. Aby upewnić się, że inny węzeł może uzyskać dostęp do bazy danych, wystąpienia klastrów trybu failover wymagają jakiejś formy magazynu udostępnionego. W przypadku architektur opartych na systemie Windows Server można to osiągnąć za pośrednictwem udziału plików Azure Premium, iSCSI, dysku udostępnionego platformy Azure, Miejsca do magazynowania Direct (S2D) lub obsługiwanego rozwiązania innej firmy, takiego jak SIOS DataKeeper. Wystąpienia klastrów trybu failover korzystające z wersji Standard Edition programu SQL Server mogą mieć maksymalnie dwa węzły. Wystąpienia klastrów trybu failover wymagają również używania usług domena usługi Active Directory Services (AD DS) i usług nazw domen (DNS), dzięki czemu usługi AD DS i DNS muszą być implementowane gdzieś na platformie Azure, aby wystąpienie klastra trybu failover działało.
Korzystając z systemu Windows Server 2016 lub nowszego, wystąpienia klastrów trybu failover mogą używać repliki magazynu do tworzenia natywnego rozwiązania odzyskiwania po awarii dla wystąpień klastra trybu failover bez konieczności używania innej funkcji, takiej jak wysyłanie dzienników lub grupy zabezpieczeń.
Zawsze włączone grupy dostępności
Grupy Zabezpieczeń zostały wprowadzone w programie SQL Server 2012 Enterprise Edition i w wersji SQL Server 2016, są również w wersji Standard Edition. W wersji Standard Edition grupa dostępności może zawierać jedną bazę danych, natomiast w wersji Enterprise Edition grupa dostępności może mieć więcej niż jedną bazę danych. Grupy Zabezpieczeń współdzielą pewne podobieństwa z wystąpieniami klastrów trybu failover, ale w większości przypadków są różne.
Największą różnicą między wystąpieniem klastra trybu failover a grupą dostępności jest zapewnienie ochrony na poziomie bazy danych. Replika podstawowa jest wystąpieniem uczestniczącym w grupie dostępności zawierającej bazy danych odczytu/zapisu. Replika pomocnicza to miejsce, w którym podstawowy wysyła transakcje za pośrednictwem transportu dziennika, aby zachować synchronizację. Przenoszenie danych między repliką podstawową może być synchroniczne lub asynchroniczne. Bazy danych w dowolnej repliki pomocniczej są w stanie ładowania, co oznacza, że mogą odbierać transakcje, ale nie mogą być w pełni zapisywalną kopią, dopóki ta replika nie stanie się podstawową. Grupa dostępności w wersji Standard Edition może mieć co najwyżej dwie repliki (jedną podstawową, jedną pomocniczą), natomiast wersja Enterprise Edition obsługuje maksymalnie dziewięć (jedną podstawową, osiem pomocniczych). Replika pomocnicza jest inicjowana z kopii zapasowej bazy danych lub w programie SQL Server 2016, można użyć funkcji o nazwie "automatyczne rozmieszczanie". Automatyczne rozmieszczanie używa transportu strumienia dziennika do przesyłania strumieniowego kopii zapasowej do repliki pomocniczej dla każdej bazy danych grupy dostępności przy użyciu skonfigurowanych punktów końcowych.
Grupa dostępności zapewnia abstrakcję z odbiornikiem. Odbiornik działa jak unikatowa nazwa przypisana do wystąpienia klastra trybu failover i ma własną nazwę i adres IP, który różni się od innych elementów (WSFC, node itp.). Odbiornik wymaga również modułu równoważenia obciążenia i przechodzi przez zatrzymanie i uruchomienie. Aplikacje i użytkownicy końcowi mogą używać odbiornika do nawiązywania połączenia, ale w przeciwieństwie do wystąpienia klastra trybu failover, jeśli jest to konieczne, odbiornik nie musi być używany. Połączenia bezpośrednio z wystąpieniem mogą wystąpić. W wersji Enterprise Edition repliki pomocnicze w wersji Enterprise Edition można również skonfigurować pod kątem dostępu tylko do odczytu, jeśli jest to konieczne, i można ich używać do innych funkcji, takich jak kontrole spójności bazy danych (DBC) i kopie zapasowe.
Grupy Zabezpieczeń mogą mieć szybszy czas pracy w trybie failover w porównaniu z wystąpieniem klastra trybu failover, co jest jednym z powodów, dla których są atrakcyjne. Grupy Zabezpieczeń nie wymagają magazynu udostępnionego, ale każda replika ma kopię danych, co zwiększa łączną liczbę kopii bazy danych i ogólnych kosztów magazynowania. Magazyn jest lokalny dla każdej repliki. Jeśli na przykład ślad danych baz danych w repliki podstawowej wynosi 1 TB, każda replika będzie również mieć taką samą wartość. Jeśli istnieje pięć replik, oznacza to, że potrzebujesz 5 TB miejsca.
Należy pamiętać, że każdy obiekt, który istnieje poza bazą danych lub nie jest przechwytywany w dzienniku transakcji bazy danych, musi zostać utworzony ręcznie i uwzględniony w innym wystąpieniu programu SQL Server, jeśli wystąpienie musi stać się nową repliką podstawową. Przykłady obiektów, które będą odpowiedzialne za zadania agenta programu SQL Server, identyfikatory logowania na poziomie wystąpienia i serwery połączone. Jeśli możesz użyć uwierzytelniania systemu Windows lub użyć zawartych baz danych z grupami zabezpieczeń, uprości to dostęp.
Wiele organizacji może napotkać wyzwania związane z wdrażaniem architektur o wysokiej dostępności i może potrzebować tylko wysokiej dostępności zapewnianej przez platformę Azure lub korzystania z rozwiązania PaaS, takiego jak usługa Azure SQL Managed Instance. Zanim przyjrzymy się rozwiązaniom platformy Azure, istnieje jeszcze jedna funkcja programu SQL Server, o której należy wiedzieć: wysyłanie dzienników.
Wysyłanie dziennika
Wysyłanie dzienników trwa od wczesnych dni programu SQL Server. Ta funkcja jest oparta na kopii zapasowej, kopiowaniu i przywracaniu oraz jest jedną z najprostszych metod uzyskiwania usługi HADR dla programu SQL Server. Wysyłanie dzienników jest używane głównie do odzyskiwania po awarii, ale może być również używane do zwiększenia dostępności lokalnej.
Wysyłanie dzienników, takie jak grupy AG, zapewnia ochronę na poziomie bazy danych, co oznacza, że nadal musisz uwzględnić zadania agenta programu SQL Server, serwery połączone, identyfikatory logowania na poziomie wystąpienia itp. Nie ma abstrakcji zapewnianej natywnie przez wysyłanie dzienników, więc przejście na inny serwer uczestniczący w wysyłaniu dziennika musi być w stanie tolerować zmianę nazwy. Jeśli nie jest to możliwe, istnieją metody, takie jak alias DNS, które można skonfigurować w warstwie sieciowej, aby spróbować rozwiązać problemy ze zmianą nazwy.
Mechanizm wysyłania dziennika jest prosty: najpierw wykonaj pełną kopię zapasową źródłowej bazy danych na serwerze podstawowym, przywróć ją w stanie ładowania (STANDBY lub NORECOVERY) na innym wystąpieniu znanym jako serwer pomocniczy lub rezerwa ciepła. Ta nowa kopia bazy danych jest znana jako pomocnicza baza danych. Zautomatyzowany proces wbudowany w program SQL Server automatycznie utworzy kopię zapasową dziennika transakcji podstawowej bazy danych, skopiuj kopię zapasową na serwer rezerwowy, a na koniec przywróci kopię zapasową do rezerwowego.
Funkcje HADR programu SQL Server nie są jedynymi opcjami zwiększania dostępności IaaS. Na platformie Azure istnieją pewne funkcje, które należy również wziąć pod uwagę.