Planowanie i wdrażanie planu wysokiej dostępności i odzyskiwania po awarii, który spełnia wszystkie umowy dotyczące poziomu usług, jest przedsięwzięciem nietrywialnym i wymaga bardzo jasnego zrozumienia mocnych i słabych stron SQL Server. Podczas dopasowywania wymagań do kombinacji funkcji, niektóre krytyczne szczegóły mogą zostać pominięte, a w tym poście omówię kilka typowych zniekształceń i złych założeń, które mogą wkraść się do rozwiązania – ostatecznie powodując, że nie trafimy w cel zgodnie z naszymi docelowymi punktami odzyskiwania i czasem odzyskiwania. Niektóre z przykładów zniekształceń lub złudzeń, które tutaj opisuję, można uogólnić na różne funkcje, a niektóre są specyficzne dla funkcji.
„Przetestowaliśmy nasz plan odzyskiwania po awarii, gdy po raz pierwszy uruchomiliśmy nasz projekt i wiemy, że zadziała”
Pracowałem z klientami, którzy rzeczywiście mieli „właściwe” podejście do odzyskiwania po awarii – raz. Jednak gdy wszyscy poczuli się pewni skuteczności rozwiązania, nie przeprowadzono już żadnych innych ćwiczeń odzyskiwania po awarii. Oczywiście – w międzyczasie warstwa danych i aplikacja zmieniają się w czasie. Zmiany te wprowadzają nowe obiekty i procesy, które są krytyczne dla aplikacji. A nawet jeśli po premierze wszystko pozostaje statyczne, nadal musisz liczyć się z rotacją personelu i różnymi zestawami umiejętności. Czy dzisiejsi pracownicy mogą z powodzeniem przeprowadzić ćwiczenie odzyskiwania po awarii? A nawet najlepsi pracownicy potrzebują ciągłej praktyki.
„Nie stracimy danych, ponieważ używamy synchronicznego dublowania baz danych”
Załóżmy, że używasz synchronicznego dublowania bazy danych między dwiema instancjami SQL Server, przy czym każda instancja znajduje się w osobnym centrum danych. W tym przykładzie załóżmy, że opóźnienie transakcji jest akceptowalne, mimo że jest to synchroniczna sesja dublowania bazy danych z kilkoma kilometrami między centrami danych. Nie masz świadka w miksie, ponieważ chcesz ręcznie kontrolować przełączanie awaryjne dublowania bazy danych.
Załóżmy teraz, że Twoje centrum danych odzyskiwania po awarii zniknie, ale Twoje główne centrum danych jest nadal dostępne. Główna baza danych jest odłączona od dublowanej bazy danych, ale nadal akceptuje połączenia i modyfikacje danych. A co z wymogiem „bez utraty danych” teraz? Jeśli transakcje przebiegały z odłączonym zleceniodawcą przez kolejną godzinę, jaki masz plan, jeśli główne centrum danych również zostanie utracone?
„Nasz właściciel firmy twierdzi, że możemy stracić do 12 godzin danych”
Ważne jest, aby kilka pytań zadać więcej niż raz i więcej niż jednej osobie w organizacji. Jeśli ktoś powie Ci, że „12 godzin utraty danych jest dopuszczalne” – zapytaj go ponownie lub zapytaj, jakie byłyby konsekwencje tej utraty danych. Zapytaj także innych ludzi. Mogą stawiać znacznie bardziej rygorystyczne wymagania. Odkryłem, że cele punktu przywracania wymagają pewnych negocjacji i więcej niż kilku przemyślanych, przemyślanych dyskusji.
„Korzystamy z [dublowania bazy danych lub grup dostępności], więc jesteśmy zabezpieczeni na wypadek awarii”
Grupy dublowania bazy danych i dostępności z pewnością mogą być używane do ochrony na poziomie bazy danych, ale co z wszystkim innym? A co z twoimi loginami? Pakiety SSIS? Oferty pracy? Bazy danych modelu odzyskiwania bez PEŁNEGO? Połączone serwery?
„Używamy funkcji SQL Server XYZ, więc nie stracimy żadnych transakcji w locie”
Nie, przykro mi. Chociaż niektóre funkcje umożliwiają przejrzyste przekierowanie, nie jest to to samo, co zachowywanie i utrzymywanie otwartych transakcji w czasie przełączania awaryjnego. Żadna funkcja SQL Server nie zapewnia dziś takiej funkcjonalności.
"Zespół obsługujący warstwę danych dla tej aplikacji nie znosi funkcji SQL Server XYZ, ale idziemy dalej, ponieważ to właśnie polecił nam zewnętrzny konsultant"
Chociaż byłoby miło, gdyby ludzie nie rozwijali określonych uprzedzeń dotyczących funkcji SQL Server, często tak nie jest. Jeśli próbujesz wymusić rozwiązania na pracownikach, których nie ma na pokładzie, ryzykujesz z góry ustaloną porażkę. W ramach ćwiczeń HA/DR, w których pomogłem w przeszłości, zawsze jestem zainteresowany słuchaniem o wcześniejszych doświadczeniach ludzi z określonymi cechami. Na przykład niektóre firmy bardzo dobrze wykorzystują setki wystąpień klastrów pracy awaryjnej, podczas gdy inne unikają ich z powodu złych doświadczeń z poprzednich wersji. Planując rozwiązanie, nie można pominąć historii ani predyspozycji personelu, który ostatecznie będzie odpowiedzialny za wdrożenie i wsparcie rekomendowanego rozwiązania.
„Jako administrator baz danych decyduję, której technologii HA/DR użyć w warstwie danych, więc będziemy korzystać z grup dostępności w przyszłości”
Administrator bazy danych może potencjalnie skonfigurować dublowanie bazy danych przy niewielkim lub żadnym zaangażowaniu innych zespołów. Teraz z grupami dostępności, nawet jeśli administrator bazy danych mógłby to wszystko zrobić samodzielnie, może to być nierozsądne. W końcu — jeśli wdrażasz grupy dostępności na potrzeby odzyskiwania po awarii, chcesz, aby wszyscy zaangażowani w operację odzyskiwania po awarii znali Twoje rozwiązanie i wymagania potrzebne do pomyślnego powrotu do trybu online i odzyskiwania danych. W przypadku grup dostępności musisz pomyśleć o klastrze trybu failover systemu Windows Server, konfiguracjach kworum, głosowaniu węzłów, odbiorniku grupy dostępności i nie tylko. Jeśli będziesz potrzebować innych osób do ułatwienia rozwiązania, upewnij się, że są zaangażowane w wstępne zalecenie.
„Używamy grup dostępności, dzięki czemu możemy mieć dostępność tylko do odczytu w przypadku awarii naszej repliki do odczytu i zapisu”
To tylko jeden przykład scenariusza „co jeśli”. Przy każdej implementacji funkcji będziesz chciał sobie wyobrazić różne sposoby, w jakie może wystąpić awaria – a następnie przetestuj ją, aby upewnić się, że Twoje wymagania są nadal spełniane. Na przykład — jeśli uważasz, że asynchroniczne repliki tylko do odczytu Twojej grupy dostępności programu SQL Server 2012 będą dostępne, gdy replika do odczytu i zapisu jest niedostępna, będziesz niemile zaskoczony, gdy zobaczysz komunikat Unable to access database 'XYZ' because its replica role is RESOLVING which does not allow connections wiadomość w produkcji.
"Przetestowaliśmy funkcję SQL Server XYZ i przełączanie awaryjne było szybkie, więc ustaliliśmy, że możemy łatwo osiągnąć nasze cele dotyczące czasu odzyskiwania"
Załóżmy, że decydujesz się na użycie dublowania bazy danych w celu zapewnienia wysokiej dostępności na poziomie bazy danych użytkownika. Potrzebujesz szybkiego przełączania awaryjnego (mierzonego w sekundach), a podczas testowania rzeczywiście widzisz szybkie przełączanie awaryjne. Ale czy był to realistyczny test? Czy zmuszałeś do znacznego nakładu pracy? W przykładzie dublowania bazy danych najdłuższą częścią operacji przełączania awaryjnego mogą być operacje ponawiania. Jeśli nie prowadzisz realistycznych obciążeń, nie możesz naprawdę powiedzieć, że przełączanie awaryjne będzie faktycznie „szybkie”.
„Jeśli mamy katastrofę i musimy odzyskać i uzgodnić dane, rozwiążemy to, gdy nadejdzie czas”
To jest trudne. Załóżmy, że masz katastrofę i musisz uruchomić dodatkowe centrum danych. Decydujesz się na wymuszenie obsługi najbardziej krytycznych baz danych w dodatkowym centrum danych i masz teraz podział w linii modyfikacji danych (niektóre nieuzgodnione wiersze w głównym centrum danych, a teraz nowe modyfikacje w dodatkowym centrum danych). W końcu Twoje główne centrum danych zostanie przeniesione do trybu online — ale teraz masz dane, które muszą zostać odzyskane i uzgodnione, zanim będzie można ponownie ustanowić ogólne rozwiązanie HA/DR. Co robisz? Co możesz zrobić? Ta dyskusja rzadko jest łatwa do przeprowadzenia i może zależeć od kilku czynników, takich jak zakupione pakiety oprogramowania, złożoność warstwy danych i dostępne narzędzia do konwergencji danych. W rzeczywistości dyskusja jest zwykle tak trudna, że ludzie w ogóle jej nie mają. Ale jeśli dane są na tyle krytyczne, że możesz skonfigurować dodatkowe centrum danych, kluczowa część dyskusji powinna dotyczyć tego, jak najlepiej uratować dane, a także uzgodnić je po wystąpieniu katastrofy.
Podsumowanie
Ten artykuł zawierał tylko kilka przykładów tego, jak możemy łudzić się, że rozwiązanie w pełni spełnia ich wymagania. Chociaż leży to w ludzkiej naturze – jeśli chodzi o utratę danych i ciągłość biznesową, nasza praca będzie zależeć od tego, czy będziemy bardziej agresywni w testowaniu naszych własnych przekonań i założeń.
