© 2010 Quest Software, Inc. ALL RIGHTS RESERVED Utrzymanie wysokiej dostępności środowisk bazodanowych (na przykładzie Oracle) Maciej Pogorzelski Product.

Author: Dorofiej Pruchnik

0 downloads 2 Views

2 2 Agenda SLA (Service Levels Agrements) Maksymalna ciągła wydajność Wyzwania w zapewnieniu Dostępności i Wydajności Aplikacji –Eliminacja Fragmentacji danych –Redukcja wpływu raportów na pracę użytkowników online –Poprawa skalowalności aplikacji –Integracja Aplikacji w czasie rzeczywistym –Migracja bez przestoju w pracy użytkowników –Monitorowanie wykorzystywanych mechanizmów

4 4 Perspektywa użytkownika końcowego Service Levels Dostęp do Aplikacji Szybki Czas odpowiedzi Czego oczekują użytkownicy

5 5 5 Dostępność Aplikacji Czasy Odpowiedzi Mierzenie poziomów SLA

6 6 Perspektywa administratora

7 7 Złożoność środowiska

8 8 Wyzwanie: Wykrywanie i izolacja problemów

9 9 The Impact of Planned Downtime Planowany przestój jest największym powodem, że aplikacje i systemy nie są dostępne, odpowiadając za 90% czasu niedostępności systemów korporacyjnych.... od 70 do 90 procent przestojów jest związane bezpośrednio z planowanymi działaniami. nieplanowanych przestojów stanowi obecnie jedynie około 20 procent wszystkich przestojów.

11 11 Maksymalna ciągła wydajność Wyzwania Dostępności Reorganizacje w celu odzyskania przestrzeni Upgradey baz danych i systemów operacyjnych Migracji i konsolidacja platform i storage Wyzwania Wydajności Generowanie raportów ma wpływ na użytkowników online Centralna autoryzacja ogranicza skalowalność aplikacji e-business Opóźnienia w synchronizacji danych zmniejszają wydajność aplikacji Maintain maximum performance & availability for critical business applications during periods of traditional outage and slowdown Maintain maximum performance & availability for critical business applications during periods of traditional outage and slowdown

12 12 Ważne pojęcia Całkowita Redundancja Danych Replikacja blisko czasu rzeczywistego –Niski narzut na wydajność –Wysoka wydajność –Wieloplatformowość –Zapewnienie integralności danych integrity

14 14 Oracle - Fragmentacja W bazie Oracle występują fragmentacja na trzech poziomach –Segmentów, Bloków i Wierszy Fragmentacja na poziomie segmentów –Ma wpływ na wolną jak i zaalokowaną przestrzeń –Problem rozwiązała wprowadzenie LMT (locally managed tablespaces)

15 15 Fragmentacja Block Fragmentation HWM (high water mark) vs Actual Used Wasted Space powoduje intensywne operacje I/O Intensywne operacje I/O powodują spowolnienie zapytań i zmniejszenie czasu odpowiedzi Before Reorg After Reorg

16 16 Wpływ fragmentacji na poziomie bloków SAP Table:ANLV Table Size:37.07MB Oracle:9.2.0.2 Block Fragmentation: 59.25% Row Fragmentation: 0.0% Performance Metric Before Reorg After Reorg Percentage Difference Transactions Per Sec (TPS) 21.6931.20+43.85% Rows Returned During Test 6,67811,165+67.19% Average Time0.8190.539+34.19%

17 17 Fragmentacja Fragmentacja Wierszy Pofragmentowane wiersze (Chained rows) rozrzucone są pomiędzy wiele bloków Jeśli wiersz nie mieści się bloku powoduje migracje do nowego bloku Odczytywanie wiersza wymaga przeskakiwania pomiędzy wierszami Odpytanie chained row generuje narzut przynajmniej 100% większy niż zapytania do wiersza nie pofragmentowanego

18 18 Wpływ fragmentacji na poziomie wierszy Środowisko –Raport SAP:ZLSDRS0039 –Ilość Tabeles:10 –Reorg.Tabela:VBAP –Oracle:9.2.0.2 –Wielkość Tabeli:25.27GB –Fragmentacja Bloków:0.00% –Fragmentacja Wierszy:3.96% Wyniki –Czas wykonywania raportu skrócił się o 27.90%

19 19

20 20

21 21 Jak działa Reorganizacja Live Reorg

22 22 Jak działa Reorganizacja Live Reorg 1.Stworzenie kopii 2.Wyłapywanie transakcji zmieniających dane Reorg Table 1 2 Production Table

23 23 How to LiveReorg a Database 1.Stworzenie kopii 2.Wyłapywanie transakcji zmieniających dane i synchronizacja po kopiowaniu tabeli Reorg Table 2 Production Table

24 24 How to LiveReorg a Database 1.Create a copy of the table 2.Wyłapywanie transakcji zmieniających dane i synchronizacja po kopiowaniu tabeli 3.Przełączenie table bez przestoju w pracy użytkowników Production Table Original Table

25 25 Singapore Utility Company SAP Table Reorg SAP Table (DBERDZ) –1.86TB tabela, 312GB indeksy Ilość Transakcji w czasie reorganizacji –Inserts:7,236,202 –Updates:5,276,000 –Deletes:90,492 Czas zaoszczędzony –Kopiowanie Tabeli:95 h –Tworzenie Indeksów:33 h No Downtime Eliminated 5.3 days of outage No Downtime Eliminated 5.3 days of outage Continuous Performance Over 12.6M transactions Continuous Performance Over 12.6M transactions LiveReorg

26 26 Space Manager with LiveReorg Wydajność i Odzyskiwanie wolnego miejsca –Poprawia Czas odpowiedzi dal użytkowników online –Przyspiesza raporty działające na dużych woluminach danych –Optymalizuje wykorzystanie przestrzeni dyskowych Niewielki wpływ na reorganizowane systemy Chroni Dostępność –Możliwe utrzymanie zerowej niedostępności

28 28 Generowanie Reportów Wpływa na czasy odpowiedzi dla użytkowników Online Accounting CRM Zdalne zapytania Raporty Hurtownie i Backupy Billing Użytkownicy Online

29 29 Możliwe rozwiązania Alokacja czasowa zasobów pomiędzy zadania –Okno dla operacji Online (eg: 9am – 5pm) –Okno dla Reportów(eg: 5pm – 9am) Nie jest to akceptowalne dla większości krytycznych aplikacji biznesowych Wykonywanie Migawek (Snapshot s) Baz na Server Raportujący –Regularne odświeżanie danych produkcyjnych –Odtwarzanie Oracle i generowanie raportów Wystarczające do cyklicznych raportów Nie aktualne dane wymagające zarządzanie

30 30 Case Study: Honeywell (aplikacja finansowa Oracle) zamykanie misiąca skrócono z 5 dni do 3 poprzez wykorzystanie Shareplex zmniejszenie wpływu na 800 użytkowników poprzez uniknięcie wielu kilkudziesięciu minutowych przestojów Serwer Raportujący przy użyciu Shareplex Raporty Hurtownie i Backupy Accounting CRM Zdalne zapytania Billing Użytkownicy Online SharePlex

31 31 Quest SharePlex Wysoko wydajna replikacja oparta o pliki dziennika powtórzeń (Redo log) Daje nieprzerwany dostęp do bazy target Niski narzut na wydajność, przy minimalnym opóźnieniu Rozszerza możliwości technologii klastrowych SourceTarget

32 32 Architektura Shareplex Capture Read ExportImport Post Capture Queue Export Queue Post Queue SQL Redo-Logs SourceTarget

34 34 Poprawa skalowalności aplikacji Buyers (write) e-commerce Wysoki współczynnik Browse-to-Buy Browsers (read-only) Browsers (read-only) Browsers (read-only) Browsers (read-only) Browsers (read-only) Browsers (read-only) Browsers (read-only) Browsers (read-only)

35 35 Buyers (write) e-commerce Browsers (read-only) Browsers (read-only) Browsers (read-only) Browsers (read-only) Browsers (read-only) Browsers (read-only) Browsers (read-only) SharePlex Case Study: BTexact (UK ) wykorzystanie wielu niewielkich serwerów do autoryzacji użytkowników wzrost skalowalności z 1,5 do 3 millionów użytkowników oszczędności liczone w milionach funtów znaczny wzrost czasu odpowiedzi Horyzontalna Skalowalność aplikacji e-commerce

37 37 Integracja Aplikacji A Singapore Transport Company Aplikacja A Zarządza wszystkimi Klientami i dostawcami na całym świecie Aplikacja B Zarządza wszystkimi Operacjami Wewnętrznymi i Logistyką

38 38 Integracja Aplikacji A Singapore Transport Company Integracja Aplikacji Muszą nieprzerwanie Wymieniać dane

39 39 Integracja Aplikacji A Singapore Transport Company Opcja1: Technologia EAI Współdzielone dane muszą być przechowywane we w miarę prostym modelu Mała lub brak wbudowanej logiki Znaczny czas i umiejętności potrzebne do implementacji Rozwiązania EAI używają triggerów bazodanowych do wychwytywania danych – duży narzut wydajnościowy na system

40 40 Integracja Aplikacji A Singapore Transport Company Opcja1: Technologia EAI Współdzielone dane muszą być przechowywane we w miarę prostym modelu Mała lub brak wbudowanej logiki Znaczny czas i umiejętności potrzebne do implementacji Rozwiązania EAI używają triggerów bazodanowych do wychwytywania danych – duży narzut wydajnościowy na system

41 41 Integracja Aplikacji A Singapore Transport Company Opcja 2: Wewnętrzny dewelopment Zapewnia dużą elastyczność rozwiązania Duży koszty utrzymania i modyfikacji Cięzkie zapewnienie spójności danych Ciężko ustrzec się wielu błędów

42 42 Integracja Aplikacji A Singapore Transport Company Opcja 2: Wewnętrzny dewelopment Zapewnia dużą elastyczność rozwiązania Duży koszty utrzymania i modyfikacji Cięzkie zapewnienie spójności danych Ciężko ustrzec się wielu błędów

43 43 Integracja Aplikacji A Singapore Transport Company Rozwiązanie: SharePlex Replikacja danych w czsie rzeczywistym Szybki we wdrożeniu i łatwy w zarządzaniu Spójność danych wbudowane w Oracle, wymuszana przez wykorzystanie plików (Redo Log) Niski narzut wydajnościowy nie wymagający upgradu sprzętu SharePlex bi-directional

45 45 SAP Downtime Management Migration using Shareplex for Oracle and Interim System Destination SystemOriginal SystemInterim System 2 – System Copy 3 – Shareplex Activate 4 – SAP Startup 5 - Dump data 1 - SAP Shutdown 6 – Data Transfer SAP Downtime 7 – Data Load 8 – Shareplex Aligns 9 – SAP Shutdown 10 – Steps to finish Migration 11 – SAP Startup Shareplex Replica

46 46 Migracja Vodafone, Włochy Problem: wyliczono 148 godzin przestoju potrzebnych do wykonania migracji bazy1.8TB Environment: środowisko SAP –Zmiana wersji Oracle Używając Shareplex zredukowano czas przestoju do 9.5 godziny

47 47 Migracja SAP w Volvo Cel: -Migracja krytycznego środowiska SAP do nowej platformy sprzętowej Wymagania: -Blisko 100% dostępności (okno serwisowe 4 godziny w niedzielę) -Możliwość cofnięcia się do stabilnie działającego systemu w razie problemów -Możliwość ciągłej pracy użytkowników -Brak możliwości zastosowania standardowego importu/exportu z powodu nie akceptowalnego przestoju w pracy systemu (ok. 12 godzin)

48 48 Migracja SAP w Volvo Realizacja: -Migracja za pomocą Shareplex - zredukowano czas przestoju do 2 godzin. Nie został bardziej zredukowany tylko z powodu problemów z siecią niezależnych od Shareplex -Aplikacja mogła być przetestowana przed przełączeniem użytkowników co pozwoliło zmniejszyć ryzyko niepowodzenia migracji -Po przetestowaniu i przełączeniu użytkowników na nowy system replikacja została skonfigurowana w drugą stronę co dawało możliwość powrotu do pierwotnej konfiguracji w każdej chwili

49 49 Biuro Informacji Kredytowej (BIK) Cel: -Zmiana platformy sprzętowej -Przejście z pojedynczej instancji do klastra RAC Wymagania: -Zmniejszenie czasu niedostępności do 6 godzin potrzebnych na przeprowadzenie testów funkcjonalnych -Po wykonaniu przełączeniu użytkowników na nowy system, utrzymywanie starego środowiska przez jakiś czas -Po zakończeniu procesu migracji wykorzystanie systemu do replikacji na system raportowy

50 50 SharePlex Benefits for Migration Niezależność od platformy –Umożliwia migrację pomiędzy platformami Niezależność od wersji bazy Oracle –Daje możliwość podniesienia wersji Oracle Wysoka wydajność –Jest w stanie obsługiwać wiele transakcji Niski narzut na wydajność –Wykorzystanie skanowania plików dziennika powtórzeń (Redo log)

52 52 Web Servers Application Servers Foglight Experience Monitor & Experience Viewer Appliances Foglight Management Server (FMS) including the Performance Management Database (PMDB) Internet/ WAN End Users and Transaction Players Quest Collectors (Local or Remote) Database Servers Switch Foglight Application Performance Monitoring 3 rd party event integration

53 53 Space Manager - Live Activity Profiler (LAP) Monitors aktywności dla poszczególnych obiektów przed rozpoczęciem reorganizacji Pozwala na wybór najlepszego momentu rozpoczęcia reorganizacji oraz momentu przełączenia

54 54 Space Manager - Live Activity Profiler (LAP)

55 55 Space Manager - Live Activity Profiler (LAP)

56 56 Space Manager - Live Activity Profiler (LAP)

57 57 Space Manager - QSA SNMP trap Wysyłanie alarmów w razie przerwania reorganizacji

58 58 Space Manager - QSA SNMP trap Wysyłanie alarmu do Foglight

59 59 Monitorowanie i Administracja - SharePlex Manager SharePl ex Replicati on Server Agent Adapter MySQL or Oracle Reposi tory Statistic gathering http access

60 60 SharePlex Manager Widok na replikację views i Instancje Opóźnienia i alarmy

61 61 Szczegóły Replikacji Architektura SharePlex –Procesy –Kolejki –Kondycja, Opóźnienie

62 62 Szczegóły Procesów Statystyki dla procesów

63 63

64 64

© 2010 Quest Software, Inc. ALL RIGHTS RESERVED Utrzymanie wysokiej dostępności środowisk bazodanowych (na przykładzie Oracle) Maciej Pogorzelski Product.

Recommend Documents