Zapewnienie wysokiej dostępności baz Marcin Szeliga MVP SQL Server MCT
Agenda Techniki zapewniania wysokiej dostępności baz Zasada działania mirroringu baz Wdrożenie mirroringu Planowanie Konfiguracja Monitorowanie Optymalizacja
Techniki zapewniania wysokiej dostępności baz Dostępność : W przypadku systemów dostępnych przez całą dobę, siedem dni w tygodniu i 365 dni w roku, dostępność na poziomie trzech dziewiątek (99,9%) oznacza 525 minut (niecałe 9 godzin) w skali roku, podczas których serwer może być niedostępny.
Techniki zapewniania wysokiej dostępności baz Podstawowe: brak przełączania, możliwość utraty Backup / restore Detach / copy / attach Lepsze: ręczne przełączanie, możliwość utraty Peer-to-Peer Replication Log Shipping Najlepsze: automatyczne przełączanie, bez utraty Database Mirroring Failover Clustering
Podstawowe techniki zapewniania wysokiej dostępności baz Cechy wspólne Ręczne wykrycie i przełączenie Możliwość utraty Działają na poziomie bazy Standardowe systemy Brak raportowania Istnieje kopia bazy Klient musi wiedzieć kiedy ponownie się przyłączyć Backup / Restore Mały rozmiar tylko używane strony są kopiowane Można odtworzyć do punktu w czasie Dłuższy czas Detach / Copy / Attach Całe pliki Nie można odtworzyć logów
Ręczne techniki zapewniania wysokiej dostępności baz Oba zapewniają kopie bazy i wymagają ręcznego przełączania Replikacja od SQL Server 6.0 Gdy potrzebna jest dostępność i skalowalność czytania Failover możliwy (custom ) Może obejmować podzbiór bazy Kopia jest dostępna do odczytu Log Shipping Idea: Backup, Copy, Restore Log zawsze zadziała ale brakuje automatyzacji Na poziomie bazy Baza dostępna do odczytu Trzeba odłączyć użytkowników żeby zaaplikować log
Failover Clustering Wykorzystuje Microsoft Server Clusters (MSCS) Wiele węzłów zapewnia dostępność, przezroczyste dla klienta 2, 4, lub 8 węzłów zależnie od wersji systemu Automatyczne wykrywanie i przełączanie Wymaga certyfikowanego sprzętu Scenariusze: Multiple Active Instances, N+1, N+I
Database Mirroring Hot Standby Rozwiązanie fault-tolerant dla bazy Building block dla złożonych rozwiązań Database Failover Bardzo szybki Bez utraty Automatyczne lub ręczne przełączenie Automatyczna resynchronizacja po przełączeniu Automatyczne, przezroczyste przekierowanie klienta
Agenda Techniki zapewniania wysokiej dostępności baz Zasada działania mirroringu baz Wdrożenie mirroringu Planowanie Konfiguracja Monitorowanie Optymalizacja
Zasada działania mirroringu baz Dziennik transakcyjny Aplikacja kliencka 3 1 SQL Server 2 Plik dziennika 4 Plik
Zasada działania mirroringu baz Synchroniczny mirroring Aplikacja kliencka Witness Principal 5 Mirror 1 SQL Server 2.a SQL Server 2 6 4 3 6 Plik dziennika Plik Plik dziennika Plik
Zasada działania mirroringu baz Asynchroniczny mirroring Aplikacja kliencka Principal 3 Mirror 1 4 SQL Server SQL Server 2 7 6 5 7 Plik dziennika Plik Plik dziennika Plik
Agenda Techniki zapewniania wysokiej dostępności baz Zasada działania mirroringu baz Wdrożenie mirroringu Planowanie Konfiguracja Monitorowanie Optymalizacja
Planowanie Wymagania Wskazania Licencje Migawki podwojonej bazy Aplikacje klienckie
Planowanie Tryby mirroringu High Availability High Protection High Performance Automatyczne wykrywanie Automatyczne przełączanie Synchroniczny mirroring Wymaga witness Wydajność Principal zależy od parametrów łącza Brak detekcji Ręczne przełączanie Synchroniczny mirroring Nie wymaga witness Wydajność Principal zależy od parametrów łącza Brak detekcji Ręczne przełączanie asynchroniczny mirroring Nie wymaga witness Wydajność Principal nie zależy od parametrów łącza Co to jest kworum?
Planowanie Czy w przypadku awarii utracimy jakieś dane? Czas Principal Wysłana część dziennika Transakcje wymagające zatwierdzenia. Ich liczba determinuje czas udostępnienia bazy po awarii głównego serwera Mierzone przez licznik wydajności Redo Queue Niewysłana część dziennika zawiera transakcje które mogą zostać utracone. Mierzona przez licznik wydajności Log Send Queue Mirror
Konfiguracja Zestawienia fizycznego połączenia pomiędzy serwerami Odtworzenia kopi podwajanej bazy na serwerze zapasowym Utworzenia relacji zaufania pomiędzy serwerami Utworzenia punktów końcowych komunikacji (ang. Endpoints) Uruchomienia sesji podwajania bazy
Mirroring baz Demonstracja
Monitorowanie Stany podwojonej bazy Monitor mirroringu Rozwiązywanie problemów Zamiana ról Ręczna Wymuszona Automatyczna
Automatyczna zamiana ról Jak długo baza będzie niedostępna? Awaria Powiadomienie świadka Udostępnienie bazy Czas wykrycia awarii Narzut Czas Wykrycie awarii Zakończenie fazy Redo Faza Redo Faza Undo
Optymalizacja Wytyczne Opóźnienie łącza nie powinno przekraczać: 20 milisekund (sync) 100 milisekund (async) Przepustowość łącza powinna być znacznie większa niż liczba wysyłanych w ciągu sekundy transakcji: 10 MB/s (sync) 1 MB/s (async) Rozmiar transakcji!
Optymalizacja Liczniki wydajności: Obu serwerów: Sends/sec, Recives/sec Bytes send/sec, Bytes recived/sec Serwera głównego: Log Bytes Sent/sec Log Send Queue KB Serwera zapasowego: Log Bytes Recived/sec Redo Queue Redo Bytes/sec
Optymalizacja Czas potrzebny na odtworzenie spójności podwojonej bazy przez serwer zapasowy możemy obliczyć ze wzoru (Redo Queue) / (Redo Bytes/sec). Czas potrzebny do odebrania przez serwer zapasowy wszystkich transakcji możemy obliczyć ze wzoru (Log Send Queue KB) / ( Log Bytes Recived/sec).
Mirroring baz Dodatkowa demonstracja
Zapewnienie wysokiej dostępności baz Marcin Szeliga Marcin_Szeliga@css.pl MVP SQL Server MCT