Konsolidacja OPITZ CONSULTING Kraków Jacek Sapiński KRK Event OPITZ CONSULTING Kraków 211 Strona 1
1 Konsolidacja OPITZ CONSULTING Kraków 211 Strona 2
Sytuacja uwarunkowana historycznie A 1 5 Application A B 1 5 1 1 2 3 4 5 6 7 8 9 1 11 12 13 14 15 16 17 18 19 2 21 22 23 24 25 26 27 28 29 3 Application B 1 2 3 4 5 6 7 8 9 1 11 12 13 14 15 16 17 18 19 2 21 22 23 24 25 26 27 28 29 3 Application C C 5 1 1 2 3 4 5 6 7 8 9 1 11 12 13 14 15 16 17 18 19 2 21 22 23 24 25 26 27 28 29 3 Application D D 5 1 2 3 4 5 6 7 8 9 1 11 12 13 14 15 16 17 18 19 2 21 22 23 24 25 26 27 28 29 3 OPITZ CONSULTING Kraków 211 Strona 3
Dlaczego klastry, dlaczego RAC? Czy RAC jest potrzebny w moim przedsiębiorstwie? Sporo szumu wokół tej technologii, ale czy moje przedsiębiorstwo rzeczywiście potrzebuje technologii klastrowych? Nie muszę być (pseudo)nowoczesny/a chcę, by to zwyczajnie i po prostu zdało egzamin! OPITZ CONSULTING Kraków 211 Strona 4
Dlaczego klastry, dlaczego RAC? parę wątpliwości... To jest (zbyt) droga technologia! To jest stosunkowo skomplikowana i zawodna technologia.! Nie każda aplikacja nadaje się do migracji na RAC RAC się kiepsko skaluje! OPITZ CONSULTING Kraków 211 Strona 5
Dlaczego klastry, dlaczego RAC? parę pytań (do słuchacza) Planowe lub nieplanowane przerwy w dostępności danych? 5-15%? (CPU, RAM, bandwidth)? Istniejąca infrastruktura może nie podołać stosunkowo krótkim okresom przeciążeń? Silnie scentralizowane rozwiązanie? Mała elastyczność? Wysokie koszty? OPITZ CONSULTING Kraków 211 Strona 6
2 Konsolidacja scalajmy, ale odpowiedzialnie... baza sprzętowa podlega wymianie co 5(?) lat OPITZ CONSULTING Kraków 211 Strona 7
Konsolidacja: dobre wykorzystanie zasobów A 1 5 Application A B C 1 5 1 5 1 1 1 2 3 4 5 6 7 8 9 1 11 12 13 14 15 16 17 18 19 2 21 22 23 24 25 26 27 28 29 3 9 8 7 6 Application B D 5 1 2 3 4 5 6 7 8 9 1 11 12 13 14 15 16 17 18 19 2 21 22 23 24 25 26 27 28 29 3C 4 B 3 2 1 Application C 1 2 3 4 5 6 7 8 9 1 11 12 13 14 15 16 17 18 19 2 21 22 23 24 25 26 27 28 29 3 1 2 3 4 5 6 7 8 9 1 11 12 13 14 15 16 17 18 19 2 21 22 23 24 25 26 27 28 29 3 Application D A D 5 1 2 3 4 5 6 7 8 9 1 11 12 13 14 15 16 17 18 19 2 21 22 23 24 25 26 27 28 29 3 OPITZ CONSULTING Kraków 211 Strona 8
Konsolidacja: dobre wykorzystanie zasobów Obciążenie pochodzące od serwerów aplikacji Load Z pewnością ważne bazy danych SGA 1GB, PGA 8GB, avg CPU 15% SGA 5GB, PGA 8GB, avg CPU 5% SGA 12GB, PGA 8GB, avg CPU 12% SGA 4GB, PGA 3GB, avg CPU 15% SGA 1GB, PGA 8GB, avg CPU 9% SGA 1GB, PGA 8GB, avg CPU 11% SGA 1GB, PGA 8GB, avg CPU 15% SGA 12GB, PGA 8GB, avg CPU 13% SGA 2GB, PGA 16GB, avg CPU 25% W porządku.., CapEx i OpEx uległy zmniejszeniu, ale czy śpimy spokojnie? Może da się lepiej..? OPITZ CONSULTING Kraków 211 Strona 9
Konsolidacja: rozłożenie obciążenia na klaster 1 5 A 1 9 1 1 2 3 4 5 6 7 8 9 1 11 12 13 14 15 16 17 18 19 2 21 22 23 24 25 26 27 28 29 3 8 B 57 6 5 D 1 2 3 4 5 6 7 8 9 1 11 12 13 14 15 16 17 18 19 2 21 22 23 24 25 26 27 28 29 3C 1 4 B C 3 A 5 2 1 1 5 1 2 3 4 5 6 7 8 9 1 11 12 13 14 15 16 17 18 19 2 21 22 23 24 25 26 27 28 29 3 1 2 3 4 5 6 7 8 9 1 11 12 13 14 15 16 17 18 19 2 21 22 23 24 25 26 27 28 29 3 D 1 2 3 4 5 6 7 8 9 1 11 12 13 14 15 16 17 18 19 2 21 22 23 24 25 26 27 28 29 3 OPITZ CONSULTING Kraków 211 Strona 1
Konsolidacja: co gdy obciążenie wzrośnie...?! 1 1 2 9 9 18 8 8 16 7 7 14 6 6 12 5 5 1 4 4 8 3 3 6????????? 2 2 4 1 1 2 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 9 1 111 1112 1213 1314 1415 16 17 18 19 2 21 22 23 24 25 26 27 28 29 3 D DD C CC B BB A AA OPITZ CONSULTING Kraków 211 Strona 11
Metody kontroli zasobów Hard Partitioning processor sets (Solaris, HP-UX), processor affinity (AIX) Przypisuje proces (aplikacje) do konkretnego procesora Nie jest dostępny na każdą platformę O/S Workload Manager (CPU i pamięć) Workload Manager (HP-UX, AIX), Solaris Resource Manager Nie jest dostępny na każdą platformę Virtualization Izolacja VM (konfiguracja VM) Narzut administracyjny, koszty licencjonowania Instance Caging Oracle Resource Manager(Resource Plan) Korzysta ze wszystkich CPU OPITZ CONSULTING Kraków 211 Strona 12
3 Instance Caging OPITZ CONSULTING Kraków 211 Strona 13
Instance Caging (IC) 11gR2!!! Ogranicza liczbę używanych CPU dla poszczególnych instancji Oracle 1. TYLKO CPU 2. Nie dotyczy procesów background 3. Jest niezależny od platformy IC korzysta z: Oracle Database Resource Manager parametru cpu_count Wykorzystywany w: Systemach produkcyjnych Systemach testowych, developerskich lub o znikomym obciążeniu Instance Caging + IO Resource Manager w Exadata OPITZ CONSULTING Kraków 211 Strona 14
IC Over Provisioning Bazy generujące małe obciążenie CPU Brak potrzeby izolacji Instancja ma wpływ na wydajność pozostałych Narzucenie limitu użycia liczby CPU na każdą instancję 12 9 6 Sum CPU 3 Instancja D: cpu_count =3 Instancja C: cpu_count =3 Instancja B: cpu_count =3 Instancja A: cpu_count =3 Suma cpu_count dla wszystkich instancji przekracza liczbę fizycznych CPU na maszynie cpu_limita / (cpu_limita + cpu_limitb + cpu_limitc + cpu_limitd) OPITZ CONSULTING Kraków 211 Strona 15
IC - Partitioning Systemy produkcyjne Duże obciążenie instancji dzielących wspólny serwer Systemy krytyczne Izolacja wykorzystania CPU Instancja nie może mieć wpływu na wydajność pozostałych Zasoby CPU instancji są stałe, wiec łatwiej przewidzieć wydajność CPU 32 24 16 8 Instancja D: cpu_count =4 Instancja C: cpu_count =4 Instancja B: cpu_count =8 Instancja A: cpu_count =16 Sum CPU Suma cpu_count dla wszystkich instancji nie przekracza liczby fizycznych CPU na maszynie OPITZ CONSULTING Kraków 211 Strona 16
Instance Caging konfiguracja + monitoring Konfiguracja Instance Caging Alter system set cpu_count = 8; (uwaga: liczba CPU Xeon) Resource Manager Alter system set resource_manager_plan = DEFAULT_PLAN ; Monitoring SQL> select name, to_char(start_time,'mon DD HH24:MI') start_time, to_char(end_time,'mon DD HH24:MI') end_time, WINDOW_NAME from v$rsrc_plan_history order by START_TIME NAME START_TIME END_TIME WINDOW_NAME ------------------------------ ------------ ------------ --------------- DEFAULT_PLAN JAN 18 15:23 JAN 18 17:26 JAN 18 17:26 JAN 18 22: DEFAULT_MAINTENANCE_PLAN JAN 18 22: JAN 19 2: TUESDAY_WINDOW JAN 19 2: JAN 19 1:28 DEFAULT_PLAN JAN 19 1:28 JAN 19 12:13 SQL> select name,cpu_managed from V$rsrc_plan where is_top_plan='true'; NAME CPU -------------------------------- --- DEFAULT_PLAN ON OPITZ CONSULTING Kraków 211 Strona 17
Czas (s) Instance Caging test Serwer Rack Fujitsu RX1S6 Intel Xeon Processor X345 # of Cores 4 # of Threads 8 2x DB11gR2 (DB1, DB2) FOR i in 1..6 LOOP myid := myid*(myid/counter) - counter; counter := counter * round(myid,5) + myid*counter + 1.123; END LOOP; 9 8 7 6 5 4 3 2 1 IC - czasy wykonania 1 2 3 4 5 time DB1 time DB2 DB1 cpu/db2 cpu 8-7-1 6-2 5-3 4-4 time DB1(s) 118 139 165 22 241 time DB2(s) 771 374 281 244 OPITZ CONSULTING Kraków 211 Strona 18
Instance Caging wyniki testu Tasks: 8 running Cpu :1.%us,.%sy Cpu1 :1.%us,.%sy Cpu2 :1.%us,.%sy Cpu3 :1.%us,.%sy Cpu4 :1.%us,.%sy Cpu5 :1.%us,.%sy Cpu6 :1.%us,.%sy Cpu7 : 99.7%us,.3%sy Tasks: 2 running Cpu : 23.5%us,.%sy Cpu1 : 25.7%us,.%sy Cpu2 : 23.1%us,.%sy Cpu3 : 43.%us,.%sy Cpu4 :.3%us,.%sy Cpu5 : 27.2%us,.%sy Cpu6 : 24.7%us,.%sy Cpu7 : 3.3%us,.%sy DB1 cpu_count = 6 DB2 cpu_count = 2 Procs -----cpu------ r us sy id wa st 8 92 8 8 91 9 8 91 9 procs -----cpu------ r us sy id wa st 2 25 75 2 25 75 2 25 75 OPITZ CONSULTING Kraków 211 Strona 19
Kontakt Jacek Sapiński, Kierownik PASM jacek.sapinski@opitz-consulting.com tel. +48 12 617 181 tel. kom. +48 519 39 71 Jakub Szepietowski, Młodszy konsultant SE jakub.szepietowski@opitz-consulting.com tel. +48 12 617 1819 OPITZ CONSULTING Kraków 211 Strona 2
Pytania/Odpowiedzi OPITZ CONSULTING Kraków 211 Strona 21