[Źródło] Wysoka dostępność w SQL Server (1) ---- przegląd wysokiej dostępności

Od SQL Server 2005 Microsoft dostarcza różnorodne technologie wysokiej dostępności, które ograniczają przestoje i zwiększają ochronę danych biznesowych, a wraz z ciągłym wydawaniem SQL Server 2008, SQL Server 2008 R2 i SQL Server 2012 w SQL Server dostępnych jest wiele technologii wysokiej dostępności, które sprostoją w różnych sytuacjach.

    Zanim zacznę ten artykuł, przedstawię krótkie podsumowanie tego, co decyduje o tym, jaką technologię wysokiej dostępności użyć.

    Wiele firm potrzebuje, aby całość lub część ich danych była dobrze dostępna, na przykład strony sklepów internetowych, bazy produktów muszą być dostępne 24/7, w przeciwnym razie w bardzo konkurencyjnym środowisku rynkowym przestoje oznaczają utratę klientów i przychodów. Na przykład w call center korzystającym z SQL Server, jeśli baza danych przestanie działać, wszyscy dzwoniący mogą tylko siedzieć i odpowiadać klientowi "Przepraszam, awaria systemu", co również jest nie do przyjęcia.

    Oczywiście w idealnym świecie wszystkie krytyczne dane byłyby dostępne przez cały czas, ale w rzeczywistości istnieje wiele powodów, dla których baza danych jest niedostępna, ponieważ nie da się przewidzieć czasu i formy katastrofy, dlatego konieczne jest wcześniejsze podjęcie działań, aby zapobiec różnym sytuacjom awaryjnym, dlatego SQL Server oferuje różnorodne technologie wysokiej dostępności, które obejmują głównie: klasterowanie, replikację, lustrzanie, dostarczanie logów, grupy dostępności AlwaysOn oraz inne, takie jak kopie zapasowe i przywracanie grup plików, Technologie wysokiej dostępności w pojedynczej instancji, takie jak indeksy odbudowy online. Wykorzystanie technologii wysokiej dostępności nie polega na wyborze znanej technologii do bezpośredniego użytku, lecz na kompleksowym rozważeniu biznesu i technologii. Ponieważ nie ma jednej technologii, która mogłaby spełnić wszystkie funkcje. Wdrażanie tych technologii w oparciu o konkretną firmę i budżet to tzw. strategia wysokiej dostępności.

Projektując strategię wysokiej dostępności, najpierw powinieneś wziąć pod uwagę następujące czynniki:

• RTO (Recovery Time Objective) – czyli cel czasu odzyskania, oznacza, ile czasu przestojów jest dozwolone, zwykle wyrażanych kilkoma 9, na przykład 99,999% dostępności oznacza nie więcej niż 5 minut przestojów rocznie, 99,99% dostępności oznacza nie więcej niż 52,5 minuty przestojów rocznie, a 99,9% dostępności oznacza nie więcej niż 8,75 godziny przestojów rocznie. Warto zauważyć, że metoda obliczeń RTO uwzględnia, czy system ma 24*365, czy tylko od 6:00 do 21:00 itd. Trzeba także zwrócić uwagę, czy okno utrzymania jest liczone jako przestoj, a łatwiej jest osiągnąć wyższą dostępność, jeśli podczas tego okna konserwacja są dozwolone i łatki związane z utrzymaniem bazy danych.
• RPO (Recovery Point Objective) – znane również jako cel punktu odzyskania, oznacza, ile utraty danych jest dozwolone. Zazwyczaj, jeśli zrobisz dobrą kopię zapasową, możesz bez problemu osiągnąć zerową utratę danych. Jednak gdy dochodzi do katastrofy, w zależności od stopnia uszkodzenia bazy danych, czas potrzebny na przywrócenie danych z kopii zapasowej spowoduje, że baza danych stanie się niedostępna, co wpłynie na wdrożenie RTO. Wczesnym i bardziej znanym przykładem jest system bankowy w Europie i Stanach Zjednoczonych, biorąc pod uwagę tylko RPO – w systemie są tylko pełne kopie zapasowe i logi, pełne kopie co 3 miesiące, logi co 15 minut, a gdy dochodzi do katastrofy, tylko pełne kopie zapasowe, a logi mogą przywrócić dane, więc choć nie ma utraty danych, to ponieważ przywrócenie danych trwało dwa pełne dni, system bankowy był niedostępny przez 2 dni, przez co straciono wielu klientów. Innym przeciwieństwem przykładem jest krajowa strona wideo online, wykorzystująca SQL Server jako relacyjną bazę danych, front-end korzysta z NoSQL i regularnie importuje dane No-SQL do relacyjnej bazy jako kopię zapasową.
  

    Budżet – RTO i RPO są łącznie znane jako SLA (Umowy o Poziomie Usług), a projektując strategię wysokiej dostępności, musisz ocenić, jak dobrze spełniasz SLA w zależności od swojej firmy, w zależności od budżetu oraz mierzyć koszty różnych SLA w przypadku awarii. Ogólnie rzecz biorąc, trudno jest osiągnąć wysokie SLA przy ograniczonym budżecie, a nawet jeśli wysokie SLA są osiągane dzięki złożonym architekturom, to złożone architektury oznaczają również wysokie koszty eksploatacji i utrzymania, dlatego konieczne jest dobranie odpowiedniej technologii w ramach budżetu, aby spełnić wymagania SLA.

Dlatego ogólnie rzecz biorąc, szeroki system wysokiej dostępności można określić na podstawie kilku pytań dotyczących przyjmowania zamówień:

• Jaki czas przestoju akcjonariusze są skłonni zaakceptować?
• Jakie przestoje są akceptowalne dla menedżerów?
• Jaki jest budżet przewidziany na scenariusz wysokiej dostępności?
• Ile wynosi strata na godzinę z powodu przestojów?
  

• Zimna kopia zapasowa: Serwer rezerwowy jest skonfigurowany tak, aby przyjmować dane serwera głównego, a w przypadku awarii ręcznie przywracać dane do bazy głównej lub rekonfigurować ciąg połączeń lub uprawnienia programu, aby uruchomić bazę zapasową.
• Ciepła kopia zapasowa: Dane serwera pierwotnego będą nieprzerwanie przesyłać logi do serwera zapasowego (w nieregularnych odstępach, może to być 15 minut, 30 minut, 1 minuta itd.), w ten sposób serwer główny do serwera zapasowego jest zwykle aktualizowany asynchronicznie, więc dane serwera głównego i serwera zapasowego nie mogą być gwarantowane. Ponadto ten schemat zazwyczaj nie implementuje automatycznego monitorowania awarii ani przełączania awaryjnego.
• Kopia zapasowa na gorąco: Dane serwera głównego są automatycznie synchronizowane na serwerze zapasowym, a w większości przypadków uwzględniane są automatyczne monitorowanie awarii i przełączanie awaryjne, a spójność danych między serwerem głównym i serwerem zapasowym może być gwarantowana.
  

    Od zimnych do ciepłych i gorących zapasów koszty gwałtownie rosną.

    Funkcje wysokiej dostępności obsługiwane w SQL Server są ściśle powiązane z wersją, a wersja Enterprise obsługuje wszystkie funkcje wysokiej dostępności, w tym:

• Klaster awaryjny
• l Obraz bazy danych
• Transmisja dziennika transakcji
• l Migawki bazy danych
• Ulepszenia o wysokiej dostępności
• l Pamięć gorącego obciążenia
• l Operacje indeksowania online
• l Częściowo online baza danych (tylko grupa plików głównych lub grupa plików głównych oraz dodatkowe pliki NDF są przywracane)
  

    Aby uzyskać konkretne wersje z funkcjami wysokiej dostępności, zobacz:http://msdn.microsoft.com/zh-cn/library/cc645993.aspxWarto zauważyć, że darmowa wersja Express może służyć jako serwer świadków do mirroringu baz danych, co przekłada się na oszczędności kosztów.

Klaster awaryjny

    Klastry failover zapewniają wysoką dostępność dla całej instancji SQL Server, co oznacza, że instancja SQL Server na węźle klastra przełącza się na inne węzły z powodu błędów sprzętowych, systemów operacyjnych itp. Wysoka dostępność osiąga się dzięki wielu serwerom (węzłom) współdzielącym jeden lub więcej dysków, a klastry awaryjne pojawiają się w sieci podobnie jak pojedynczy komputer, ale o wysokiej dostępności. Ważne jest, aby zauważyć, że ponieważ klastry awaryjne opierają się na współdzielonych dyskach, istnieje jeden punkt awarii dysku, dlatego na poziomie dysku należy wdrożyć dodatkowe zabezpieczenia, takie jak replikacja SAN. Najczęściej spotykanym klastrem awaryjnym jest klaster awaryjne z dwoma węzłami, obejmujący master i slave.

Transmisja dziennika transakcyjnego

    Wysyłka dziennika transakcyjnego zapewnia ochronę wysokiej dostępności na poziomie bazy danych. Logowanie służy do utrzymywania jednej lub więcej baz danych rezerwowych (zwanych "bazami wtórnymi") odpowiadającej bazy produkcyjnej (zwanej "bazą podstawową"). Przed nastąpieniem failoveru wtórna baza danych musi zostać w pełni zaktualizowana poprzez ręczne zastosowanie wszystkich nieprzywróconych kopii zapasowych logów. Dostarczanie logów ma elastyczność obsługiwania wielu baz danych rezerwowych. Jeśli wymagane jest wiele alternatywnych baz danych, dostarczanie logów może być stosowane osobno lub jako uzupełnienie mirroringu baz danych. Gdy te rozwiązania są używane razem, główna baza danych aktualnej konfiguracji mirroring danych jest jednocześnie główną bazą danych aktualnej konfiguracji wysyłania logów.

    Dostarczanie dziennika transakcyjnego może być używane do wykonywania zimnych i ciepłych kopii zapasowych.

Lustrzane odbicie baz danych

    Lustrzane odbicie bazy danych to w rzeczywistości rozwiązanie programistyczne, które zapewnia ochronę na poziomie bazy danych, zapewniając niemal natychmiastowe przełączanie awaryjne w celu poprawy dostępności bazy danych. Lustrzane odbicie bazy danych może być używane do utrzymania pojedynczej bazy danych rezerwowej (lub "bazy lustrzanej") dla odpowiadającej bazy produkcyjnej (zwanej "główną bazą danych").
Ponieważ baza danych lustrzana jest zawsze w stanie przywracania, ale nie jest przywracana, nie można uzyskać bezpośredniego dostępu do bazy mirror. Jednak dla ładowania tylko do odczytu, takich jak raporty, można używać bazy lustrzanej pośrednio, tworząc migawkę bazy danych z lustrzaną bazą danych. Migawki bazy danych zapewniają klientom dostęp tylko do odczytu do danych w bazie danych po ich utworzeniu. Każda konfiguracja mirroringu bazy danych obejmuje "główny serwer", który zawiera główną bazę danych, a także serwer lustrzany, który zawiera mirrored database. Serwer lustrzany nieustannie aktualizuje bazę danych lustrzanych o główną bazę danych.
    Lustrzane odbicia baz danych działają synchronicznie w trybie wysokiego bezpieczeństwa lub asynchronicznie w trybie wysokiej wydajności. W trybie wysokiej wydajności transakcje nie muszą czekać, aż serwer lustrzany zapisze logi na dysku, zanim mogą zostać przesłane, co maksymalizuje wydajność. W trybie wysokiego bezpieczeństwa zobowiązane transakcje są dokonywane przez obu partnerów, ale czas opóźnienia transakcji jest wydłużony. Najprostsza konfiguracja mirroringu bazy danych obejmuje tylko główny serwer i serwer lustrzany. W tej konfiguracji, jeśli serwer główny zostanie utracony, serwer lustrzany może być używany jako serwer rezerwowy, ale może to powodować utratę danych. Tryb wysokiego bezpieczeństwa obsługuje konfigurację w trybie czuwania, tryb wysokiego bezpieczeństwa z automatycznym przełączaniem awaryjnym. Ta konfiguracja obejmuje instancję serwera zewnętrznej zwanej "serwerem świadkiem", która umożliwia użycie serwera lustrzanego jako serwera kopii zapasowej na gorąco. Przełączanie awaryjne z bazy głównej do bazy mirror zwykle trwa kilka sekund.

    Lustrzane odbicie bazy danych może być stosowane zarówno do kopii zapasowych ciepłej, jak i gorącej.

kopiować

    Replikacja nie jest ściśle funkcją zaprojektowaną pod kątem wysokiej dostępności, ale można ją zastosować do wysokiej dostępności. Replikacja zapewnia ochronę na poziomie obiektów bazy danych. Replikacja wykorzystuje model publikuj-subskrybuj, gdzie dane są publikowane przez serwer główny, znany jako wydawca, dla jednego lub więcej drugorzędnych lub subskrybentów. Replikacja zapewnia dostępność w czasie rzeczywistym i skalowalność między tymi serwerami. Obsługuje filtrowanie, aby zapewnić subskrybentom podzbiór danych, a także aktualizacje partycji. Subskrybent jest dostępny online i umożliwia raportowanie lub inne funkcje bez konieczności odzyskiwania zapytań. SQL Server oferuje cztery typy replikacji: replikację migawki, replikację transakcyjną, replikację peer-to-peer oraz replikację scalaną.

AlwaysOnGrupa użyteczności

    AlwaysOn Availability Groups to nowa funkcja wprowadzona w SQL Server 2012. Zapewniona jest również ochrona na poziomie bazy danych. Rozszerza również limit, że mirroring bazy danych może wynosić tylko 1:1, tak że jedna replika główna może odpowiadać maksymalnie 4 replikom wtórnym (w SQL Server 2014 limit ten został rozszerzony do 8), z czego 2 repliki wtórne mogą być synchronizowane jako kopie zapasowe na gorąco i repliki główne w czasie rzeczywistym, a pozostałe dwie asynchroniczne repliki pomocnicze mogą być używane jako kopie zapasowe ciepłe. Dodatkowo, repliki wtórne mogą być skonfigurowane jako tylko do odczytu i mogą być używane do obsługi obciążenia kopii zapasowych.

    Z tego powodu mirroring bazy danych jest oznaczony jako "przestarzały" w SQL Server 2012.

    Po zrozumieniu podstawowych koncepcji wysokiej dostępności oraz technologii wysokiej dostępności oferowanych w SQL Serverze, przyjrzyjmy się projektowi strategii wysokiej dostępności. Planowanie strategii wysokiej dostępności można podzielić na cztery etapy:

Wymagania dotyczące zbierania

    Pierwszym krokiem w wyborze strategii wysokiej dostępności jest bez wątpienia zebranie wymagań biznesowych w celu ustanowienia SLA. RTO i RPO są najważniejszymi elementami, na których opiera się realistyczne oczekiwania dotyczące wymagań dostępności oraz realizuje strategię wysokiej dostępności opartą na tych oczekiwaniach.

Limity oceny

    Ograniczenia oceny nie ograniczają się tylko do różnych technologii wysokiej dostępności w SQL Server, ale także do tych nietechnicznych. Jeśli masz budżet wynoszący tylko dziesiątki tysięcy juanów, ale chcesz stworzyć rozwiązanie o wysokiej dostępności oparte na zewnętrznych centrach danych i replikacji SAN, to bez wątpienia jest to marzenie głupca. Kolejnym nietechnicznym ograniczeniem jest poziom personelu operacyjnego, a często złożone architektury oznaczają bardziej wykwalifikowany personel operacyjny. Inne nietechniczne ograniczenia to dostępność miejsca na dysku w centrum danych, czy zasilanie i klimatyzacja spełniają wymagania oraz czas potrzebny na wdrożenie strategii dostępności.

    Ograniczenia techniczne obejmują różne funkcje i ograniczenia wysokiej dostępności, funkcje obsługiwane przez różne wersje SQL Server, liczbę procesorów oraz rozmiar pamięci. Zdecydowanie zaleca się najpierw zapoznanie się z ograniczeniami różnych wersji i funkcji SQL Server na stronie Microsoft MSDN, zanim wdrożysz politykę wysokiej dostępności.

Wybrana technologia

    Po zebraniu wymagań i ocenie ograniczeń, kolejnym krokiem jest wybór technologii lub kombinacji technologii opisanych wcześniej w tym artykule, aby spełnić wymagania SLA. Jeśli wybrana technologia nie spełnia wymagań SLA, łatwo jest zgłosić, które ograniczenia nie spełniają SLA, co pozwala na żądanie brakujących zasobów lub kompromis w sprawie SLA.

Testuj, waliduj i dokumentuj

    Polityki wysokiej dostępności muszą być rygorystycznie testowane i walidowane od samego początku, aby zapewnić, że obecne polityki dostępności spełniają SLA. Jednak gdy wdrażana jest strategia wysokiej dostępności, konieczne jest również regularne jej testowanie i walidacja, aby upewnić się, że obecna polityka nadal spełnia warunki SLA pomimo wzrostu danych, zmian biznesowych lub wymagań. Jednocześnie należy dokumentować konfigurację rozwiązania dostępności, metody przełączania awaryjnego oraz planu odzyskiwania po awarii, aby można było je śledzić w przypadku awarii lub przyszłej korekty strategii wysokiej dostępności.

Ten artykuł wyjaśnia podstawowe pojęcia wysokiej dostępności, koncepcję SLA, różne rodzaje funkcji wysokiej dostępności obsługiwane w SQL Server oraz kroki potrzebne do zaprojektowania strategii wysokiej dostępności. Warto zauważyć, że choć ten artykuł mówi wyłącznie o wysokiej dostępności na poziomie bazy danych, wysoka dostępność to nie tylko kwestia DBA, ale także współpraca różnych ról, takich jak personel operacyjny i konserwacyjny systemów, administratorzy sieci, programiści i menedżerowie, aby lepiej spełniać wymagania SLA.