ŁUKASZ SKROBOT, Konsultant techniczny Sybase Professional services

Prezentacja na temat: "ŁUKASZ SKROBOT, Konsultant techniczny Sybase Professional services"— Zapis prezentacji:

1 XII Ogólnopolskie Spotkanie Użytkowników Sybase SQL Anywhere High Availability SQL Anywhere Monitor
ŁUKASZ SKROBOT, Konsultant techniczny Sybase Professional services 19 MAJA 2009, HOTEL SOFITEL VICTORIA, WARSZAWA

2 Agenda CZĘŚĆ I SQL Anywhere High Availability, czyli jak zbudować środowisko „wysokiej dostępności”, wykorzystując SQL Anywhere. CZĘŚĆ II SQL Anywhere Monitor, czyli o tym, co to jest i do czego służy nowa funkcjonalność SQL Anywhere.

3 Część I SQL Anywhere High Availability

4 Agenda – część I SQL Anywhere High Availability (HA)
High Availability – co to jest? Database mirroring Servery partnerskie oraz rola arbitra Tryby i stany synchronizacji Zalety i korzyści Scenariusze działania

5 High Availability – co to jest?
SQL Anywhere High Availability może być rozpatrywane jako: Cluster HA – połączenie kilku maszyn (nodów) pracujących równolegle, do których z jednej strony podłączona jest aplikacja, a z drugiej strony baza danych (storage device). Client Node 1 Quorum data (single cluster storage device) Node 2 Node 3 Node 4

6 High Availability – co to jest?
SQL Anywhere High Availability może być rozpatrywane jako: Database mirror – konfiguracja dwóch lub kilku serwerów baz danych, uruchomionych na różnych maszynach, pomiędzy którymi wykonuje się synchronizacja danych. Arbiter Server Mirror Server Primary Server Database

7 Database mirroring Klasyczny układ HA – database mirroring musi zawierać przynajmniej: primary server – serwer aktywny, mirror server – serwer zapasowy (standby), arbiter server – serwer określa, który serwer jest aktualnie aktywny. Powyższą konfigurację możemy określić jako: systemem mirroringu, gdzie serwery primary i mirror to serwery partnerskie, natomiast serwer arbiter pełni rolę „sędziego”. Klient łączy się tylko do jednego serwera.

8 Mirroring system

9 Serwery partnerskie i rola arbitra
Primary server – jest to serwer aktywny, o czym decyduje arbiter, w konfiguracji tego serwera wskazuje się, który serwer dla niego jest partnerem. Mirror server – jest to serwer zapasowy (standby), który automatycznie staje się aktywnym w przypadku awarii serwera aktywnego. Arbiter server – jest przede wszystkim tym serwerem, który decyduje, który serwer jest primary (aktywny) i pozwala na automatyczny failover. W przypadku systemu mirroringu tylko jeden serwer pozwala na zapis (primary server), natomiast mirror server pracuje w trybie tylko do odczytu (read-only).

10 Tryby synchronizacji Database mirroring pozwala na użycie trzech trybów synchronizacji: tryb synchroniczny, tryb asynchroniczny, tryb asyncfullpage (nazywany również page mode).

11 Tryb synchroniczny Zmiany zatwierdzone na serwerze aktywnym są wysyłane do zapasowego i muszą być tam zatwierdzone, zanim serwer aktywny odpowie klientowi. Wprowadza pewność i bezpieczeństwo wszystkich transakcji. Tryb ten może mieć wpływ na wydajność – ze względu na wydłużony czas zatwierdzania transakcji.

12 Tryb asynchroniczny Zatwierdzone zmiany na serwerze aktywnym są wysyłane do serwera zapasowego. Serwer aktywny nie czeka na potwierdzenie ze strony serwera zapasowego. Wyższa wydajność. Potencjalna strata transakcji w wypadku, gdy nastąpi failover przed naniesieniem transakcji na serwer zapasowy. Domyślnie failover nie jest automatyczny. Opcja “Autofailover = yes” może być ustawiona.

13 Tryb page W tym trybie strony loga są wysyłane po zapełnieniu i nie są związana z operacją commit Redukuje to ruch w trakcie mirroru, a tym samym poprawia wydajność serwera primary. Parametr “pagetimeout” może określać jaki jest czas oczekiwania przed zapełnieniem strony, w celu wysłania jej do mirror servera. Zatwierdzone transakcje mogą być zgubione, jeśli nastąpi awaria serwera primary. Opcja “Autofailover” musi być ustawiona na „yes” w celu automatycznego przełączenia. Opcja „Synchronize_mirror_on_commit” może być ustawiona na „on” – synchronizacja działa jak w trybie synchronicznym.

14 Stany synchronizacji W systemie monitoringu, w przypadku wyboru trybu synchronicznego, serwery mogą znajdować się w jednym z dwóch stanów: stan synchronizacji (synchronizing), stan zsynchronizowania (synchronized).

15 Zalety i korzyści Ochrona baz danych przed błędem systemu.
Prosty i szybki sposób zestawienia HA. System mirroringu nie wymaga dodatkowego oprogramowania. Mały wpływ na wydajność. W przypadku niedostępności jednego z serwerów, brak przerw w działaniu aplikacji.

16 Zalety i korzyści Działający arbiter pozwala na automatyczny failover.
Brak utraty transakcji w trybie synchronicznym. Szybki failover (aktualny dziennik transakcji). Brak dodatkowych wymagań sprzętowych. Brak dodatkowych wymagań systemowych. Serwery partnerskie mogą znajdować się w różnych lokalizacjach. Serwery mogą obsługiwać mirrorowane i niemirrorowane bazy danych.

17 Scenariusz 1 – start systemu
2. Arbiter czeka na server 1 lub server 2 Arbiter server 5. Arbiter odpowiada: możesz być primary 11. Arbiter odpowiada: Server 1 jest primary Server 1 Server 2 1. Serwer 1 szuka arbitra lub servera 2 7. Serwer 2 szuka arbitra lub servera 1 3. Serwer 1 podłącza się do Arbitra 8. Serwer 2 podłącza się do Arbitra 4. Serwer 1 pyta: czy może być primary? 9. Serwer 2 podłącza się do Serwera 1 6. Akceptacja połączenia 10. Serwer 2 pyta: czy może być primary? 12. Serwer 2 staje się standby Mirroring aktywny

18 Scenariusz 2 – awaria Serwera 1
Arbiter server 1. Arbiter traci połączenie z Serwerem 1 3. Arbiter odpowiada: możesz być primary Server 1 Server 2 1. Serwer 1 ulega awarii 1. Serwer 2 traci połączenie z Serwerem 1 2. Serwer 2 pyta: czy może być primary? Serwer 2 staje się primary (aktywny)

19 Część II SQL Anywhere Monitor

20 Agenda – część II SQL Anywhere Monitor – co to jest? Architektura
Wymagania Instalacja Architektura – przykład zastosowania Demo …

21 Co to jet SQL Anywhere Monitor?
SQL Anywhere Monitor jest narzędziem administracyjnym opartym na przeglądarce internetowej, który zbiera informacje nt. pracy serwera SQL Anywhere oraz serwera MobiLink. Charakterystyczne cechy Monitora to: zbieranie informacji nt. pracy (stanu) serwerów, możliwość wysyłania wiadomości (alertów), interfejs przeglądarki internetowej, jednoczesne monitorowanie wielu serwerów, minimalny wpływ na obciążenie serwerów. To narzędzie jest graficzną „wirtualizacją” stanu pracy serwerów. Nie służy do analizy, czy optymalizacji zapytań SQL! Do tego celu służy Application Profiling Wizard.

22 Architektura SQL Anywhere Server MobiLink Server
SQL Anywhere Monitor Server SQL Anywhere Monitor Przeglądarka

23 Wymagania Monitor może pracować (jako serwer) na systemie operacyjnym Windows lub Linux. Monitor może pracować (jako klient) na każdej platformie, w której dostępna jest przeglądarka obsługująca: najnowszą wersję Adobe Flash Player lub przynajmniej w wersji 9, skrypty JavaScript. Monitor jest dostępny tylko w wersji SQL Anywhere Monitor może monitorować: ASA w wersji i wyższe, MobiLink w wersji i wyższe.

24 Instalacja

25 Architektura – przykład zastosowania
SQL Anywhere Server IP: MobiLink Server IP: SQL Anywhere Monitor Przeglądarka IP: ADMIN SQL Anywhere Monitor Przeglądarka IP: USER Sieć SQL Anywhere Monitor Server IP:

26 Agenda – część II SQL Anywhere Monitor – co to jest? Architektura
Wymagania Instalacja Architektura – przykład zastosowania Demo …

27 Demo …

28 Demo …

29 Demo …

30 Demo …

31 Demo …

32 Demo …

33 Demo …

34 Demo …

35 Dziękuję!