Oracle RAC/Weblogic Load Balancing i Failover

Transkrypt

1 Oracle RAC/WebLogic Load Balancing OPITZ CONSULTING Kraków Nowoczesne techniki konsolidacji i optymalizacji środowisk opartych o rozwiązania Oracle (2011) Piotr Sajda (kierownik Service Engineering) OPITZ CONSULTING Kraków 2011 Strona 1

2 1a RAC Jak to widzą administratorzy warstwy aplikacyjnej? OPITZ CONSULTING Kraków 2011 Strona 2

3 WLS A Multi Data Source A Data Source A1 Data Source A2 WLS B Multi Data Source B Data Source B1 Data Source B2 100Mbps (LAN) VIP1 Instance Dedicated Service (1) Instance Dedicated Service (2) VIP2 High speed Interconnect RAC node1 C 1 C 2 MIN 1Gbps C 1 RAC node2 C 2 FC Switch SAN FC Switch c1t10d11... DISK 1 DISK 2 c2t10d11... DISK 3 DISK 4 DISK 5 DISK 6 DISK 7 DISK 8 DISK 9 Shared Storage System DISK 10 DISK 11 DISK 12 OPITZ CONSULTING Kraków 2011 Strona 3

4 1b RAC - Jak to widzą DBA s? OPITZ CONSULTING Kraków 2011 Strona 4

5 WLS A Multi Data Source A Data Source A1 Data Source A2 WLS B Multi Data Source B Data Source B1 Data Source B2 VIP 1 Instance Dedicated Service (1) 100Mbps (LAN) High speed Interconnect Instance Dedicated Service (2) VIP 2 RAC node1 C 1 C 2 MIN 1Gbps C 1 RAC node2 C 2 FC Switch SAN FC Switch c1t10d11... DISK 1 DISK 2 c2t10d11... DISK 3 DISK 4 DISK 5 DISK 6 DISK 7 DISK 8 DISK 9 Shared Storage System DISK 10 DISK 11 DISK 12 OPITZ CONSULTING Kraków 2011 Strona 5

6 1c RAC - Jak to widzą administratorzy warstwy storage? OPITZ CONSULTING Kraków 2011 Strona 6

7 WLS A Multi Data Source A Data Source A1 Data Source A2 WLS B Multi Data Source B Data Source B1 Data Source B2 VIP 1 Instance Dedicated Service (1) 100Mbps (LAN) High speed Interconnect Instance Dedicated Service (2) VIP 2 RAC node1 C 1 C 2 MIN 1Gbps C 1 RAC node2 C 2 FC Switch SAN FC Switch Shared Storage System DISK 1 DISK 2 LUN DISK 3 DISK 4 DISK 5 DISK 6 DISK 7 DISK 8 DISK 9 DISK 10 DISK 11 DISK 12 OPITZ CONSULTING Kraków 2011 Strona 7

8 1d Middleware/RDBMS uważamy, że zagadnienie powinno postrzegać się komplementarnie OPITZ CONSULTING Kraków 2011 Strona 8

9 WLS A Multi Data Source A Data Source A1 Data Source A2 WLS B Multi Data Source B Data Source B1 Data Source B2 Corporate LAN (np. 100Mbps) VIP1 Instance Dedicated Service (1) High speed Interconnect Instance Dedicated Service (2) VIP2 RAC node1 RAC node2 HBA1 HBA2 min. 1Gbps HBA1 HBA2 FC Switch SAN FC Switch Shared Storage System DISK 12 DISK11 DISK 10 DISK 9 DISK 8 DISK 7 DISK 6 DISK 5 DISK 4 DISK 3 DISK 2 DISK 1 OPITZ CONSULTING Kraków 2011 Strona 9

10 1 Przedstawienie tematów OPITZ CONSULTING Kraków 2011 Strona 10

11 Wysoka dostępność (HA): Weblogic & RAC Failover/Load Balancing: Multi Data Sources, JDBC Connection Failover Agenda Oracle Services Load Balancing / Failover Client Side Load Balancing / Server Side Load Balancing Współpraca WebLogic z RAC przy rozdziale obciążenia Anatomia Load Balancing Advisory - testy OPITZ CONSULTING Kraków 2011 Strona 11

12 2 Oracle Services i ich rola w algorytmach Load Balancing OPITZ CONSULTING Kraków 2011 Strona 12

13 Oracle Services: Weblogic & RAC Failover/Load Balancing: Multi Data Sources + Dynamic Detection Przykład DYNAMIC DETECTION Sytuacja wyjściowa: Potrzeba więcej mocy dla aplikacji REP. Np. na nodzie 2, DBA zatrzymuje serwis ERP i startuje serwis REP. WLS A Multi Data Source (ERP) DS1 DS2 DS3 DS1 Weblogic Cluster WLS B Multi Data Source (REP) DS1 DS2 DS3 Korzyści: Zmiany na poziomie middleware są zbędne Weblogic rekonfiguruje przyporządkowanie źródeł danych do zmian zachodzących w niższej warstwie automatycznie. Oracle Services ERP ERP REP REP Czynność relokacji serwisów wykonana jedynie po stronie DBA. Pociąga za sobą rekonfigurację po stronie middleware inerakcja z app-adminem niepotrzebna RAC node1 RAC node2 Oracle RAC RAC node3 OPITZ CONSULTING Kraków 2011 Strona 13

14 3 Client Side Load Balancing / Server Side Load Balancing OPITZ CONSULTING Kraków 2011 Strona 14

15 Client Side Load Balancing / Server Side Load Balancing Data Source A WebLogic Multi Data Source (round robin) Data Source B Corporate LAN Client OCI? Load Balancing Decyzja po stronie klienta RAC node1 High speed Interconnect RAC node2 FC Switch min. 1Gbps SAN Shared Storage System FC Switch Czy po stronie serwera? OPITZ CONSULTING Kraków 2011 Strona 15

16 Server Side Load Balancing Load Balancing po stronie serwera Bierze pod uwagę obciążenie maszyny OPITZ CONSULTING Kraków 2011 Strona 16

17 4 Współpraca WebLogic z RAC przy rozdziale obciążenia OPITZ CONSULTING Kraków 2011 Strona 17

18 LB: Weblogic & RAC Failover/Load Balancing po stronie klienta Multi Data Source WebLogic Data Source A Multi Data Source (round robin) Corporate LAN Data Source B Zawsze: 50% 50%... bez względu na rzeczywiste rozłożenie obciążenia w obrębie węzłów klastra Instance Dedicated Service (1) 50% 50% Instance Dedicated Service (2) VIP1 RAC node1 High speed Interconnect min. 1Gbps RAC node2 VIP2 FC Switch SAN Shared Storage System FC Switch OPITZ CONSULTING Kraków 2011 Strona 18

19 Wysoka dostępność (HA): Weblogic & RAC Failover/Load Balancing po stronie serwera GridLink DataSource (>=10.3.4) ONS Client (Subscriber) WebLogic GridLink Data Source W zależności od obciążenia danego węzła może być np. : 70% 30% np. zdarzenie UP/DOWN Dla nas jednak ważniejsze: PERCENT Corporate LAN SCAN (SCAN listeners) ONS daemon (FAN events) 70% 30% ONS daemon (FAN events) RAC node1 mniej obciążony High speed Interconnect RAC node2 bardziej obciążony min. 1Gbps FC Switch SAN Shared Storage System OPITZ CONSULTING Kraków 2011 Strona 19

20 Czas trwania przetwarzania kodu + operacji na bazie (I/O) Connection Pool Inteligentne użytkowanie zasobów bazujące na spostrzeżeniu, że... Czas zbudowania nowego fizycznego połączenia, zasoby (RAM, CPU, Network) select (...) from gv$process, gv$session where (...) PGA_ALLOC_MEM PGA_MAX_MEM SID SERIAL# PROGRAM ,865,824 1,865, sqlplus@pasteur(tns 1,472,608 1,472, JDBC Thin Client 1,472,608 1,472, JDBC Thin Client Jak działa Connection Pool? Sesja użycza połączenia z puli na czas trwania operacji na bazie, po czym zwalnia (zwraca) połączenie. Przykładowy (pseudo) kod w j.java: node1 2k żądań... Web Server Dla dużych aplikacji webowych narzut na RAM i CPU byłby znaczny! 2k fizycznych połączeń... Oracle Service node2 2k żądań... Web Server Middleware pula fizycznych połączeń, np Oracle Service node1 node2 String upd="update TAB set(...) where (...)"; try{ tx.begin(); conn = pool.getconnection( ); stmt = conn.createstatement( ); stmt.executeupdate(upd); stmt.close(); tx.commit(); } catch (Exception e) { e.printstacktrace(); if (tx!= null) tx.rollback(); } finally { try{ if(conn!= null) conn.close(); } catch (SQLException sqle) { } } OPITZ CONSULTING Kraków 2011 Strona 20

21 Connection Pool a liczba aktywnych sesji Przykład: 4 node RAC cluster, stress test i wnioski WORKLOAD REPOSITORY report for DB Name DB Id Instance Inst Num Startup Time Release RAC DZHO4P DZHO4P Feb-09 12: YES Host Name Platform CPUs Cores Sockets Memory(GB) su79tb12 Solaris[tm] OE (64-bit) Snap Id Snap Time Sessions Curs/Sess Begin Snap: Feb-09 13:09: End Snap: Feb-09 13:44: Elapsed: (mins) DB Time: (mins) Load Profile Per Second Per Transaction Per Exec Per Call ~~~~~~~~~~~~ ( ) DB Time(s): DB CPU(s): Redo size: 1,122, ,104.9 Transactions: DB Time: czas spędzony na CPU (a więc praca ) + aktywnym czekaniu (np. db sequential read ) Zatem, ile właściwie było aktywnych sesji? DB Time / Elapsed, czyli: 1, (mins) / (mins) = ~55 OPITZ CONSULTING Kraków 2011 Strona 21

22 Connection Pool Parametry puli połączeń Parametry Connection Pool w definicji Data Dource w warstwie Middleware (przykład: WebLogic) <jdbc-connection-pool-params> <initial-capacity>20</initial-capacity> <max-capacity>30</max-capacity> <capacity-increment>1</capacity-increment> <shrink-frequency-seconds>900</shrink-frequency-seconds> ( ) </jdbc-connection-pool-params> Middleware Oracle RAC Wady Connection Pool? (zwłaszcza z Oracle RAC) Trudność w śledzeniu konkretnej sesji. Są jednak pewne ułatwienia: Dbms_Monitor.Serv_Mod_Act_Trace_Enable & service_name=> MYSERV Jeden plik *.trc dla całej puli połączeń do użycia z np. tkprof: narzędzie trcsess OPITZ CONSULTING Kraków 2011 Strona 22

23 Node Affinity Wierność węzłowi Sesje webowe Transakcje rozproszone W ramach jednej sesji (głównie webowej): każde następne żądanie odczytu z bazy danych często odnosi się do danych zassanych przez poprzednika... Dwufazowość operacji COMMIT W ramach jednej transakcji 2PC wymusza skierowanie jej obu gałęzi do tego samego węzła klastra. Middleware Load Balancing, np. round robin pula fizycznych połączeń, load balancing Middleware Load Balancing, np. round robin pula fizycznych połączeń, load balancing Prepare Commit node1 node2 node1 node2 OPITZ CONSULTING Kraków 2011 Strona 23

24 4 Load Balancing Advisory OPITZ CONSULTING Kraków 2011 Strona 24

25 RLB Anatomia Load Balancing Advisory (LBA) Load Balancing >= 10GR2 Od 11GR2 CLB i RLB definiujemy (także) przy pomocy srvctl, wcześniej dbms_service (uwaga : od RAC11GRx OCR nic nie wie o takim serwise!) oracle@raclab2_fuji2# srvctl add service -h Adds a service configuration to the Oracle Clusterware. Usage: srvctl add service -d <db_unique_name> -s <service_name> {-r "<preferred_list>" [-a "<available_list>"] (...) [-y {AUTOMATIC MANUAL}] [-q {TRUE FALSE}] [-x {TRUE FALSE}] [-j {SHORT LONG}] [-B {NONE SERVICE_TIME THROUGHPUT}] (...) -j <clb_goal> Connection Load Balancing Goal (SHORT or LONG). Default is LONG. -B <Runtime Load Balancing Goal> Runtime Load Balancing Goal (SERVICE_TIME, THROUGHPUT, or NONE) clb_goal SERVICE_TIME Bazuje na odpowiedzi systemu mierzonych per call : DB Time Per User Call gv$metric lub DBTIMEPERCALL- GV$SERVICEMETRIC CPU Time Per User Call - gv$metric lub CPUPERCALL - GV$SERVICEMETRIC FAN enabled GOODNESS raportowany (im mniejsza wartość, tym instancja bardziej atrakcyjna) LONG Jedyne kryterium: równa dystrybucja sesji (UWAGA: nawet jeżeli RLB ustawiony na THROUGHPUT lub SERVICE_TIME!) SHORT Kryterium: bazuje na metrykach i Load Balancing Advisory THROUGHPUT Bazuje na odpowiedzi systemu mierzonych per second : DB Time Per Second gv$metric lub DBTIMEPERSEC - GV$SERVICEMETRIC CPU Time Per Second - gv$metric lub CALLSPERSEC - GV$SERVICEMETRIC FAN enabled GOODNESS raportowany (im mniejsza wartość, tym instancja bardziej atrakcyjna) NONE (Load Balancing Advisory wyłączony) bez Fast Application Notification (FAN) GOODNESS raportowany Metryki raportowane OPITZ CONSULTING Kraków 2011 Strona 25

26 Anatomia Load Balancing Advisory (LBA) Failover/Load Balancing - rola procesu PMON SYS@RACLAB1> oradebug setospid 7721 Oracle pid: 2, Unix process pid: 7721, image: oracle@fuji1 (PMON) SYS@RACLAB1> SYS@RACLAB1> oradebug Event trace name context forever, level 16 SYSTEM: IDLE PMON on FUJI1 (node1): kmmlrl: update for session drop delta: kmmgdnu: NOFAN goodness=0, delta=100, flags=0x4:unblocked/not overloaded, update=0x6:g/d/- kmmgdnu: TESTLB goodness=101, delta=9999, flags=0x4:unblocked/not overloaded, update=0x6:g/d/- kmmlrl: 55 processes kmmlrl: node load 20 kmmlrl: instance load 4 PMON on FUJI12 (node2): kmmlrl: update for process drop delta: kmmgdnu: NOFAN goodness=0, delta=100, flags=0x4:unblocked/not overloaded, update=0x6:g/d/- kmmgdnu: TESTLB goodness=101, delta=9999, flags=0x4:unblocked/not overloaded, update=0x6:g/d/- kmmlrl: 45 processes kmmlrl: node load 5 kmmlrl: instance load 3 PMON Inst1 PMON Inst2 Trace jedenego ze SCAN LISTENERów (wszystkie otrzymują informacje od procesów PMON na każdej instancji): NA RAZIE: NIC CIEKAWEGO DLA NAS uaktualnianie SCAN Listnerów sporadycznie... SCAN Listener1 SCAN Listener2 SCAN Listener :36: : nstoupdateactive:active timeout is 0 (see nstotyp) :36: : nsopen:opening transport :36: : nsopen:transport is open :36: : nsnainit:inf->nsinfflg[0]: 0xd inf->nsinfflg[1]: 0xd :36: : nsopen:global context check-in (to slot 8) complete :36: : nsanswer:deferring connect attempt; at stage 5 OPITZ CONSULTING Kraków 2011 Strona 26

27 Anatomia Load Balancing Advisory (LBA) Failover/Load Balancing - rola procesu PMON SYSTEM: Inst1 loaded, no use of services SELECT (...) from V$SERVICEMETRIC: INST_ID BEGIN_TI END_TIME SERVICE_NAME GOODNESS DELTA CPUPERCALL DBTIMEPERCALL CALLSPERSEC DBTIMEPERSEC FLAGS PMON on FUJI1 (node1): *** :57: kmmlrl: update for process drop delta: kmmgdnu: NOFAN kmmgdnu: TESTLB 1 13:54:29 13:55:29 NOFAN :56:09 13:56:14 NOFAN :54:29 13:55:29 TESTLB :56:09 13:56:14 TESTLB :55:12 13:56:12 NOFAN :56:07 13:56:12 NOFAN :55:12 13:56:12 TESTLB :56:07 13:56:12 TESTLB goodness=0, delta=100, flags=0x4:unblocked/not overloaded, update=0x6:g/d/- goodness=12500, delta=9999, flags=0x4:unblocked/not overloaded, update=0x6:g/d/- kmmlrl: 64 processes PMON on FUJI12 (node2): *** :53: kmmlrl: update for service goodness kmmgdnu: NOFAN kmmgdnu: TESTLB goodness=0, delta=100, kmmlrl: instance load 14 Trace jedenego ze SCAN LISTENERów (wszystkie otrzymują takie same informacje): LOAD: runq on FUJI1: 20 runq on FUJI2: 0 flags=0x4:unblocked/not overloaded, update=0x6:g/d/- goodness=101, delta=9999, flags=0x4:unblocked/not overloaded, update=0x6:g/d/- kmmlrl: node load :53: : nsglgrdoregister:inst loads: ld1:0 mld1:40960 ld2:2 mld2:792 (...) :57: : nsglgrdoregister:inst loads: ld1:5107 mld1:40960 ld2:22 mld2: :57: : nsglgrdoregister:service:nofan what:4 value: :57: : nsglgrdoregister:service:nofan what:2 value: :57: : nsglgrdoregister:service:testlb what:4 value: :57: : nsglgrdoregister:service:testlb what:2 value:12500 OPITZ CONSULTING Kraków 2011 Strona 27

28 Anatomia Load Balancing Advisory (LBA) Failover/Load Balancing - rola procesu PMON SYSTEM: Both instances loaded, TESTLB used SELECT (...) from GV$SERVICEMETRIC: INST_ID BEGIN_TI END_TIME SERVICE_NAME GOODNESS DELTA CPUPERCALL DBTIMEPERCALL CALLSPERSEC DBTIMEPERSEC FLAGS PMON on FUJI1 (node1): *** :36: kmmgdnu: NOFAN kmmgdnu: TESTLB 1 14:34:29 14:35:29 NOFAN :36:04 14:36:09 NOFAN :34:29 14:35:29 TESTLB :36:04 14:36:09 TESTLB :34:12 14:35:12 NOFAN :36:02 14:36:07 NOFAN :34:12 14:35:12 TESTLB :36:02 14:36:07 TESTLB goodness=0, delta=100, flags=0x4:unblocked/not overloaded, update=0x6:g/d/- goodness=714, delta=9998, flags=0x4:unblocked/not overloaded, update=0x6:g/d/- kmmlrl: 61 processes kmmlrl: instance load 10 LOAD: runq on FUJI1: 10 runq on FUJI2: 10 PMON on FUJI12 (node2): *** :36: kmmgdnu: NOFAN kmmgdnu: TESTLB goodness=0, delta=100, flags=0x4:unblocked/not overloaded, update=0x6:g/d/- goodness=714, delta=9998, flags=0x4:unblocked/not overloaded, update=0x6:g/d/- kmmlrl: 54 processes kmmlrl: instance load 10 Trace jedenego ze SCAN LISTENERów (wszystkie otrzymują takie same informacje): kmmlrl: nsgr update returned :36: : nsglgrdoregister:inst loads: ld1:1963 mld1:40960 ld2:10 mld2: :36: : nsglgrdoregister:service:nofan what:4 value: :36: : nsglgrdoregister:service:nofan what:2 value: :36: : nsglgrdoregister:service:testlb what:4 value: :36: : nsglgrdoregister:service:testlb what:2 value: :36: : nsglgrdoregister:inst loads: ld1:2081 mld1:40960 ld2:8 mld2:792 (-> powtórzenie nsglgrdoregister:service: NOFAN i TESTLB dla drugiej instancji) OPITZ CONSULTING Kraków 2011 Strona 28

29 Anatomia Load Balancing Advisory (LBA) Failover/Load Balancing Znaczenie parametrów ldn,mldn: Node Load: ld1 aktualne obciążenie węzła (jak liczone..?) mld1 max. obciążenie (cpu_count*1024*5 = 40960) Instance Load ld2 ilość sesji typu USER mld2 max. ilość sesji z spfile Trace procesu (SCAN) Listenera : :20: : nsglgrdoregister:inst loads: ld1:1021 mld1:40960 ld2:14 mld2: :20: : nsglgrdoregister:inst loads: ld1:1272 mld1:40960 ld2:12 mld2:792 SQL*Plus : 15:20:31 SYS@RACLAB2> select inst_id, type, count(*) from gv$session g roup by inst_id, type order by 2,1 INST_ID TYPE COUNT(*) BACKGROUND 47 SQL> show parameter sessions 2 BACKGROUND 40 NAME TYPE VALUE 1 USER USER 12 sessions integer 792 GV$SERVICEMETRIC: GOODNESS DELTA Trace procesu (SCAN) Listenera - c.d.: nsglgrdoregister:service:nofan what:4 value:100 nsglgrdoregister:service:nofan what:2 value:0 nsglgrdoregister:service:testlb what:4 value:9998 nsglgrdoregister:service:testlb what:2 value:714 what:4 DELTA what:2 - GOODNESS OPITZ CONSULTING Kraków 2011 Strona 29

30 Load Balancing Advisory TEST 1 Inteligentny Load Balancing z udziałem komunikatów FAN Środowisko testowe: for i in {1..70} do sqlplus -S "/ as sysdba" FUJI1 jako OCI Client CPU load producer ONLY on & done 1 for i in {1..20} do sqlplus -S & done FUJI1 2 ESSEX: OCI Client SCAN FUJI2 FOR i in LOOP myid := myid*(myid/counter) - counter; counter := counter * round(myid,5) + myid*counter ; END LOOP; OPITZ CONSULTING Kraków 2011 Strona 30

31 Load Balancing Advisory TEST 1 Inteligentny Load Balancing z udziałem komunikatów FAN FAZA 1: Sytuacja wyjściowa: ustabilizowane i równomierne obciążenie na obu nodach: SELECT * from ( select TO_CHAR(enq_time, 'HH:MI:SS') Enq_time, user_data FROM sys.sys$service_metrics_tab ORDER BY 1 desc) where rownum <= 3 USER_DATA(SRV, PAYLOAD) database=raclab service=wlslb { {instance=raclab2 percent=48 flag=good aff=false {instance=raclab1 percent=52 flag=good aff=false} } timestamp= ') FUJI1: (co 3 sekundy) # vmstat procs --cpu--- r b us sy id FUJI2: (co 3 sekundy) # vmstat procs --cpu--- r b us sy id Idle... FUJI1 FUJI2 OPITZ CONSULTING Kraków 2011 Strona 31

32 Load Balancing Advisory TEST 1 Inteligentny Load Balancing z udziałem komuniaktów FAN FAZA 2: obciążenie CPU na FUJI1: (uwaga na run queue na FUJI1 i wysyłane kom. FAN) SELECT * from ( select TO_CHAR(enq_time, 'HH:MI:SS') Enq_time, user_data FROM sys.sys$service_metrics_tab ORDER BY 1 desc) where rownum <= 3 ENQ_TIME USER_DATA(SRV, PAYLOAD) :28:45 SYS$RLBTYP('WLSLB', 'VERSION=1.0 database=raclab service=wlslb { {instance=raclab2 percent=95 flag=good aff =FALSE}{instance=RACLAB1 percent=5 flag=good aff=false} } timestamp= :28:45') 08:28:15 SYS$RLBTYP('WLSLB', 'VERSION=1.0 database=raclab service=wlslb { {instance=raclab2 percent=90 flag=good aff =FALSE}{instance=RACLAB1 percent=10 flag=good aff=false} } timestamp= :28:15') 08:27:45 SYS$RLBTYP('WLSLB', 'VERSION=1.0 database=raclab service=wlslb { {instance=raclab2 percent=81 flag=good aff =FALSE}{instance=RACLAB1 percent=19 flag=good aff=false} } timestamp= :27:45') FUJI1:(co 3sekundy) procs --cpu--- r b us sy id FUJI2: (co 3 sekundy) procs --cpu--- r b us sy id CPU load on FUJI1 1 FUJI1 FUJI2 OPITZ CONSULTING Kraków 2011 Strona 32

33 Load Balancing Advisory TEST 1 Inteligentny Load Balancing z udziałem komuniaktów FAN FAZA 3: CPU na FUJI1 wciąż obciążone. 20 przychodzących połączeń fizycznych. Wynik: 4 z instancją #1, 16 - z instancją #2 ok, tego się spodziewaliśmy, ale... CPU load on FUJI1 1 FUJI1 2 FUJI1: procs --cpu--- r b us sy id ESSEX OCI Client SCAN FUJI2 FUJI2: procs --cpu--- r b us sy id SELECT INST_ID, (...) from gv$session where username = ESSEX ; INST_ID Username STATUS START_TIME lastcall[sec.ago] ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE :29 44 OPITZ CONSULTING Kraków 2011 Strona 33

34 Load Balancing Advisory TEST 2 Inteligentny (?) Load Balancing z udziałem komunikatów FAN...uwagę zwraca stosunkowo długi czas potrzebny na rozpropagowanie komunikatów FAN : TRZY i PÓŁ MINUTY 210 sekund (!) dużo to czy mało? Powtórzmy test, nieco go modyfikując... ENQ_TIME USER_DATA(SRV, PAYLOAD) :28:45 SYS$RLBTYP('WLSLB', 'VERSION=1.0 database=raclab service=wlslb { {instance=raclab2 percent=95 flag=good aff =FALSE}{instance=RACLAB1 percent=5 flag=good aff=false} } timestamp= :28:45') saturated 08:28:15 SYS$RLBTYP('WLSLB', 'VERSION=1.0 database=raclab service=wlslb { {instance=raclab2 percent=90 flag=good aff =FALSE}{instance=RACLAB1 percent=10 flag=good aff=false} } timestamp= :28:15') 08:27:45 SYS$RLBTYP('WLSLB', 'VERSION=1.0 database=raclab service=wlslb { {instance=raclab2 percent=81 flag=good aff =FALSE}{instance=RACLAB1 percent=19 flag=good aff=false} } timestamp= :27:45') 08:27:15 SYS$RLBTYP('WLSLB', 'VERSION=1.0 database=raclab service=wlslb { {instance=raclab2 percent=69 flag=good aff =FALSE}{instance=RACLAB1 percent=31 flag=good aff=false} } timestamp= :27:15') 08:26:45 SYS$RLBTYP('WLSLB', 'VERSION=1.0 database=raclab service=wlslb { {instance=raclab2 percent=61 flag=good aff =FALSE}{instance=RACLAB1 percent=39 flag=good aff=false} } timestamp= :26:45') 08:26:15 SYS$RLBTYP('WLSLB', 'VERSION=1.0 database=raclab service=wlslb { {instance=raclab2 percent=56 flag=good aff =FALSE}{instance=RACLAB1 percent=44 flag=good aff=false} } timestamp= :26:15') 08:25:15 SYS$RLBTYP('WLSLB', 'VERSION=1.0 database=raclab service=wlslb { {instance=raclab2 percent=48 flag=good aff =FALSE}{instance=RACLAB1 percent=52 flag=good aff=false} } timestamp= :25:15') Stable, idle.. OPITZ CONSULTING Kraków 2011 Strona 34

35 Load Balancing Advisory TEST 2 Inteligentny (?) Load Balancing z udziałem komunikatów FAN FAZA 1: obciążenie CPU na FUJI1: (uwaga na run queue na FUJI1 i wysyłane kom. FAN) SELECT * from ( select user_data FROM sys.sys$service_metrics_tab ORDER BY enq_time desc) where rownum <= 3 USER_DATA(SRV, PAYLOAD) SYS$RLBTYP('WLSLB', 'VERSION=1.0 database=raclab service=wlslb { {instance=raclab2 percent=43 flag=good aff =TRUE}{instance=RACLAB1 percent=57 flag=good aff=false} } timestamp= :25:17') SYS$RLBTYP('WLSLB', 'VERSION=1.0 database=raclab service=wlslb { {instance=raclab2 percent=44 flag=good aff =TRUE}{instance=RACLAB1 percent=56 flag=good aff=false} } timestamp= :24:47') 20 new connections (phase 2, next slide) SYS$RLBTYP('WLSLB', 'VERSION=1.0 database=raclab service=wlslb { {instance=raclab2 percent=41 flag=good aff =TRUE}{instance=RACLAB1 percent=59 flag=good aff=false} } timestamp= :24:17') CPU Load on FUJI1 (phase 1) FUJI1:(co 3sekundy) procs --cpu--- r b us sy id FUJI2:(co 3sekundy) procs --cpu--- r b us sy id CPU load on FUJI1 1 FUJI1 2 ESSEX OCI Client SCAN FUJI2 OPITZ CONSULTING Kraków 2011 Strona 35

36 Load Balancing Advisory TEST 2 Inteligentny (?) Load Balancing z udziałem komunikatów FAN FAZA 2: CPU na FUJI1 max. obciążone. UWAGA: 40 sekund! później 20 przychodzących połączeń fizycznych wynik: 14 z instancją #1, 6 - z instancją #2 tego też się (niestety) spodziewaliśmy... CPU load on FUJI1 1 FUJI 1 2 ESSEX OCI Client SCAN FUJI 2 FUJI1: (co 3 sek.) FUJI2:(co 3 sek.) procs --cpu--- procs --cpu--- r b us sy id r b us sy id SELECT INST_ID, (...) from gv$session where username = ESSEX ; INST_ID Username STATUS START_TIME lastcall[sec.ago] ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE : ESSEX ACTIVE :26 76 OPITZ CONSULTING Kraków 2011 Strona 36

37 Load Balancing Advisory Load Balancing z udziałem komunikatów FAN Podsumowanie Funkcjonuje, ale wykazuje stosunkowo długi (~5 min.) czas propagacji Powyższe pozostawia nieco do życzenia, skoro strategiczna linia produktów (WebLogic i RAC 11GR2) mają wspierać LB w oparciu o FAN Niemniej: dobry kierunek, bo komunikaty async. bezp. ze źródła i na pewno lepszy niż Load Balancing w oparciu o round robin i Failover na zasadzie próbkowania w sztywnych odstępach czasowych service=wlslb { {instance=raclab2 percent=95 {instance=raclab1 percent=5} timestamp= 10:30:18') service=wlslb { {instance=raclab2 percent=94 {instance=raclab1 percent=6} timestamp= 10:29:48') service=wlslb { {instance=raclab2 percent=93 {instance=raclab1 percent=7} timestamp= 10:29:18') service=wlslb { {instance=raclab2 percent=91 {instance=raclab1 percent=9} timestamp= 10:28:48') service=wlslb { {instance=raclab2 percent=88 {instance=raclab1 percent=12} timestamp= 10:28:18') service=wlslb { {instance=raclab2 percent=80 {instance=raclab1 percent=20} timestamp= 10:27:47') service=wlslb { {instance=raclab2 percent=62 {instance=raclab1 percent=38} timestamp= 10:27:17') service=wlslb { {instance=raclab2 percent=48 {instance=raclab1 percent=52} timestamp= 10:26:47') service=wlslb { {instance=raclab2 percent=30 {instance=raclab1 percent=70} timestamp= 10:26:17') service=wlslb { {instance=raclab2 percent=37 {instance=raclab1 percent=63} timestamp= 10:25:47') service=wlslb { {instance=raclab2 percent=43 {instance=raclab1 percent=57} timestamp= 10:25:17') service=wlslb { {instance=raclab2 percent=44 {instance=raclab1 percent=56} timestamp= 10:24:47') service=wlslb { {instance=raclab2 percent=41 {instance=raclab1 percent=59} timestamp= 10:24:17') Proper information came much too late... ~5,5min Still stable and idle.. Burst connections already commenced! OPITZ CONSULTING Kraków 2011 Strona 37

38 Kontakt Piotr Sajda Kierownik Service Engineering OPITZ CONSULTING Kraków tel tel. kom OPITZ CONSULTING Kraków 2011 Strona 38

39 Pytania/Odpowiedzi OPITZ CONSULTING Kraków 2011 Strona 39