Przestoje i awarie systemu są bolesne dla administratorów baz danych, ale jeszcze bardziej dla klientów. Dzisiejsi użytkownicy oczekują prawie 100-procentowej dostępności, a cokolwiek mniej jest powodem irytacji, jeśli masz szczęście, i utraty klienta, jeśli nie.
Jednym z głównych celów DBA jest zapewnienie, że instancje i bazy danych SQL Server pozostaną w trybie online i będą działać po awarii lub awarii. Jedną z metod zwiększenia dostępności jest skonfigurowanie klastrów pracy awaryjnej systemu Windows Server z programem SQL Server.
Klaster pracy awaryjnej to grupa serwerów, które współpracują ze sobą w celu utrzymania dostępności aplikacji i usług w przypadku awarii lub awarii. Zasadniczo klaster pracy awaryjnej pobiera wszystkie dane przechowywane w instancji SQL Server i instaluje je we współdzielonym repozytorium pamięci — zwykle w sieci SAN — do którego można uzyskać dostęp z różnych serwerów.
Aby pomóc Ci rozpocząć drogę do wysokiej dostępności, przygotowaliśmy dziewięć najważniejszych nakazów i zakazów dotyczących konfiguracji klastra pracy awaryjnej SQL Server, aby zminimalizować przestoje bazy danych.
1. Nie pomijaj weryfikacji klastra.
Przed zainstalowaniem klastra konieczne jest uruchomienie sprawdzania poprawności w celu sprawdzenia konfiguracji. Jeśli jest to nowy klaster, będziesz chciał przeprowadzić wszystkie testy.
Po skonfigurowaniu klastra i całkowitym zainstalowaniu i skonfigurowaniu instancji SQL Server w klastrze, przeprowadzaj weryfikację za każdym razem, gdy wprowadzasz zmiany. Ważne jest, aby upewnić się, że wyniki walidacji są poprawne przed uruchomieniem klastra pracy awaryjnej SQL Server, aby nie trzeba było planować przestojów w celu naprawienia pominiętych problemów.
2. Dobrze skonfiguruj kworum.
Jeśli chcesz zachować program SQL Server w trybie online, upewnij się, że prawidłowo skonfigurowano kworum w klastrze pracy awaryjnej. Ta dokumentacja firmy Microsoft zawiera szczegółowe instrukcje, jak to osiągnąć, ale rolka podświetleń zawiera następujące najlepsze praktyki:
- Ponownie oceniaj kworum za każdym razem, gdy zmienia się konfiguracja klastra
- Przypisz świadka, aby uzyskać nieparzystą liczbę głosów
- W razie potrzeby usuń głosy
- Użyj funkcji „Dynamiczne kworum”, aby dynamicznie dostosowywać głosy węzłów
Należy zauważyć, że najskuteczniejszy sposób konfiguracji kworum będzie się różnić w zależności od wersji systemu Windows, liczby węzłów i niezawodności komunikacji sieciowej między węzłami,
3. Nie wybieraj niewłaściwej wersji Windows lub SQL Server.
Ten jeden rodzaj brzmi jak oczywistość, ale zawsze warto go powtórzyć. Upewnij się, że wybrałeś najnowszą wersję systemu Windows Server i upewnij się, że używasz wersji Enterprise lub Datacenter. Ponadto trzymaj się jednej wersji SQL Server, aby wszystko było proste. Przestrzeganie tych dwóch praktyk ułatwi zarządzanie klastrem i utrzymanie go w trybie online.
4. Kup odpowiedni sprzęt.
Odpowiednie dobranie sprzętu do klastra SQL Server może być trudne. Na przykład nie chcesz marnować pieniędzy na zbyt dużą ilość pamięci, ale jej zbyt mała może wpłynąć na wydajność.
Podczas opracowywania planu tworzenia klastra SQL Server upewnij się, że wymagania sprzętowe są spełnione dla odpowiedniej ilości pamięci, ścieżka sieciowa jest nadmiarowa i dokładnie oceniłeś swoje potrzeby dotyczące dysków SSD.
5. Nie umieszczaj zbyt wielu węzłów w jednym klastrze.
Możesz pokusić się o umieszczenie wszystkich swoich węzłów w jednym klastrze, ale lepiej trzymać się jednego do dwóch węzłów na klaster. Pamiętaj, że za każdym razem, gdy stosujesz poprawkę lub aktualizację do klastra, musisz przetestować, czy każda instancja nadal działa na każdym węźle. Im mniej węzłów w klastrze, tym krótsze są przestoje dla każdej instancji w przypadku awarii w każdym węźle.
6. Zaplanuj swoje węzły i instancje.
Klastry pracy awaryjnej nie są uniwersalne, więc będziesz musiał ocenić swoje potrzeby i odpowiednio zaplanować. Świetnym miejscem do rozpoczęcia jest udzielenie odpowiedzi na te pytania i odpowiednie dostosowanie klastra:
- Ile węzłów klastra potrzebujemy?
- Ile instancji SQL Server zainstalujemy?
- Ile klastrów pracy awaryjnej systemu Windows pasuje do naszych potrzeb i budżetu?
- Jakiego rodzaju pamięci użyjemy?
- Jak wygląda nasze środowisko sceniczne?
7. Nie zakładaj, że Twoje aplikacje będą działać w trybie awaryjnym.
Nigdy nie ufaj, że Twoja instancja SQL Server działa tak, jak przed wystąpieniem przełączenia awaryjnego. Niektóre aplikacje mogą później nie wrócić automatycznie do trybu online, a w zależności od aplikacji może minąć trochę czasu, zanim zauważysz.
Uczyń standardową praktyką uwzględnienie testowania aplikacji przy każdej migracji do klastra pracy awaryjnej.
8. Ponownie oceń ustawienia konfiguracji SQL Server.
Rozpoczynając fazę planowania tworzenia klastrów pracy awaryjnej SQL Server, nadszedł czas, aby ponownie przyjrzeć się ustawieniom konfiguracyjnym. Na przykład sprawdź, czy używasz najlepszych ustawień dla takich rzeczy, jak alokacja pamięci w klastrach o wielu wystąpieniach.
9. Nie zwlekaj z konwencją nazewnictwa.
Poświęć teraz trochę czasu na ostrożne nazwanie komponentów klastra i zaoszczędź sobie ogromnego bólu głowy, gdy będziesz próbował później połączyć się z serwerem. Oto kilka pomysłów, które pomogą ustanowić skuteczną konwencję nazewnictwa:
- Upewnij się, że nazwa określa typ komponentu, który oznaczasz. Czy jest to klaster, serwer fizyczny, instancja SQL Server lub Koordynator transakcji rozproszonych?
- Zainstaluj BGINFO, aby wyświetlić nazwę serwera na pulpicie dla każdego serwera w klastrze. Dzięki temu znalezienie odpowiednich baz danych jest dziecinnie proste.
- Zachowaj spójność podczas dodawania dodatkowych węzłów lub instalowania innej instancji programu SQL Server w klastrze. Jeśli będziesz trzymać się swojej konwencji nazewnictwa, nie tylko uprości to teraz, ale także ułatwi znajdowanie serwerów tym, którzy będą ich potrzebować później.
