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
1a RAC Jak to widzą administratorzy warstwy aplikacyjnej? OPITZ CONSULTING Kraków 2011 Strona 2
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
1b RAC - Jak to widzą DBA s? OPITZ CONSULTING Kraków 2011 Strona 4
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
1c RAC - Jak to widzą administratorzy warstwy storage? OPITZ CONSULTING Kraków 2011 Strona 6
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
1d Middleware/RDBMS uważamy, że zagadnienie powinno postrzegać się komplementarnie OPITZ CONSULTING Kraków 2011 Strona 8
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
1 Przedstawienie tematów OPITZ CONSULTING Kraków 2011 Strona 10
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
2 Oracle Services i ich rola w algorytmach Load Balancing OPITZ CONSULTING Kraków 2011 Strona 12
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
3 Client Side Load Balancing / Server Side Load Balancing OPITZ CONSULTING Kraków 2011 Strona 14
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
Server Side Load Balancing Load Balancing po stronie serwera Bierze pod uwagę obciążenie maszyny OPITZ CONSULTING Kraków 2011 Strona 16
4 Współpraca WebLogic z RAC przy rozdziale obciążenia OPITZ CONSULTING Kraków 2011 Strona 17
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
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
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 ------------- ----------- ------- ------- -------------------- 1,865,824 1,865,824 38 2065 sqlplus@pasteur(tns 1,472,608 1,472,608 507 1309 JDBC Thin Client 1,472,608 1,472,608 311 615 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. 50... 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
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 ------------ ----------- ------------ -------- --------------- ----------- --- DZHO4P30 2009777411 DZHO4P33 3 06-Feb-09 12:18 11.1.0.7.0 YES Host Name Platform CPUs Cores Sockets Memory(GB) ---------------- -------------------------------- ---- ----- ------- ---------- su79tb12 Solaris[tm] OE (64-bit) 64 8 1 31.84 Snap Id Snap Time Sessions Curs/Sess --------- ------------------- -------- --------- Begin Snap: 1224 06-Feb-09 13:09:09 859 1.9 End Snap: 1225 06-Feb-09 13:44:19 758 11.2 Elapsed: 35.16 (mins) DB Time: 1928.75 (mins) Load Profile Per Second Per Transaction Per Exec Per Call ~~~~~~~~~~~~ --------------- --------------- ---------- ---------- ( ) DB Time(s): 54.9 0.2 0.01 0.01 DB CPU(s): 7.7 0.0 0.00 0.00 Redo size: 1,122,648.0 3,104.9 Transactions: 361.6 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,928.75 (mins) / 35.16 (mins) = ~55 OPITZ CONSULTING Kraków 2011 Strona 21
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
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 1 2 2 1. Prepare 1 2 2 2. Commit node1 node2 node1 node2 OPITZ CONSULTING Kraków 2011 Strona 23
4 Load Balancing Advisory OPITZ CONSULTING Kraków 2011 Strona 24
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
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 10257 trace name context forever, level 16 SYSTEM: IDLE PMON on FUJI1 (node1): kmmlrl: update for session drop delta: 28062 28054 4 5 792 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: 11579 11578 45 46 511 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 Listener3 2011-01-17 12:36:00.838619 : nstoupdateactive:active timeout is 0 (see nstotyp) 2011-01-17 12:36:00.838656 : nsopen:opening transport... 2011-01-17 12:36:00.838764 : nsopen:transport is open 2011-01-17 12:36:00.838863 : nsnainit:inf->nsinfflg[0]: 0xd inf->nsinfflg[1]: 0xd 2011-01-17 12:36:00.838902 : nsopen:global context check-in (to slot 8) complete 2011-01-17 12:36:00.838937 : nsanswer:deferring connect attempt; at stage 5 OPITZ CONSULTING Kraków 2011 Strona 26
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): *** 2011-01-17 13:57:01.083 kmmlrl: update for process drop delta: 24319 24319 64 68 511 kmmgdnu: NOFAN kmmgdnu: TESTLB 1 13:54:29 13:55:29 NOFAN 0 100 0 0 0 0 4 1 13:56:09 13:56:14 NOFAN 0 100 0 0 0 0 4 1 13:54:29 13:55:29 TESTLB 12500 9999 0 0 0 0 0 1 13:56:09 13:56:14 TESTLB 12500 9999 0 0 0 0 0 2 13:55:12 13:56:12 NOFAN 0 100 0 0 0 0 4 2 13:56:07 13:56:12 NOFAN 0 100 0 0 0 0 4 2 13:55:12 13:56:12 TESTLB 101 9999 0 0 0 0 0 2 13:56:07 13:56:12 TESTLB 101 9999 0 0 0 0 0 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): *** 2011-01-17 13:53:58.189 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 0 2011-01-17 13:53:58.189670 : nsglgrdoregister:inst loads: ld1:0 mld1:40960 ld2:2 mld2:792 (...) 2011-01-17 13:57:01.459665 : nsglgrdoregister:inst loads: ld1:5107 mld1:40960 ld2:22 mld2:792 2011-01-17 13:57:01.459699 : nsglgrdoregister:service:nofan what:4 value:100 2011-01-17 13:57:01.459722 : nsglgrdoregister:service:nofan what:2 value:0 2011-01-17 13:57:01.459745 : nsglgrdoregister:service:testlb what:4 value:9999 2011-01-17 13:57:01.459767 : nsglgrdoregister:service:testlb what:2 value:12500 OPITZ CONSULTING Kraków 2011 Strona 27
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): *** 2011-01-17 14:36:03.260 kmmgdnu: NOFAN kmmgdnu: TESTLB 1 14:34:29 14:35:29 NOFAN 0 100 0 0 0 0 4 1 14:36:04 14:36:09 NOFAN 0 100 0 0 0 0 4 1 14:34:29 14:35:29 TESTLB 714 9998 478053877 600537401 0 1000 0 1 14:36:04 14:36:09 TESTLB 714 9998 4543324 5178226 10 5178 0 2 14:34:12 14:35:12 NOFAN 0 100 0 0 0 0 4 2 14:36:02 14:36:07 NOFAN 0 100 0 0 0 0 4 2 14:34:12 14:35:12 TESTLB 714 9998 3412860 4247069 2 962 0 2 14:36:02 14:36:07 TESTLB 714 9998 5556827 6291353 5 3146 0 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): *** 2011-01-17 14:36:07.903 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 0 2011-01-17 14:36:01.656086 : nsglgrdoregister:inst loads: ld1:1963 mld1:40960 ld2:10 mld2:792 2011-01-17 14:36:07.664478 : nsglgrdoregister:service:nofan what:4 value:100 2011-01-17 14:36:07.664494 : nsglgrdoregister:service:nofan what:2 value:0 2011-01-17 14:36:07.664510 : nsglgrdoregister:service:testlb what:4 value:9998 2011-01-17 14:36:07.664526 : nsglgrdoregister:service:testlb what:2 value:714 2011-01-17 14:36:07.664457 : 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
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 : 2011-01-17 15:20:15.115834 : nsglgrdoregister:inst loads: ld1:1021 mld1:40960 ld2:14 mld2:792 2011-01-17 15:20:29.853027 : 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(*) ---------- ---------- ---------- 1 BACKGROUND 47 SQL> show parameter sessions 2 BACKGROUND 40 NAME TYPE VALUE 1 USER 15 ------------------- ------- -------- 2 USER 12 sessions integer 792 GV$SERVICEMETRIC: GOODNESS DELTA -------- -------- 0 100 714 9998 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
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 FUJI1 @/opt/oracle/sqlscripts/stress_cpu_loop.sql & done 1 for i in {1..20} do sqlplus -S "essex/essex@fujirac1-scan.opitz-consulting.int:1522/wlslb" @/opt/oracle/sqlscripts/stress_cpu_loop.sql & done FUJI1 2 ESSEX: OCI Client SCAN FUJI2 FOR i in 1..60000000 LOOP myid := myid*(myid/counter) - counter; counter := counter * round(myid,5) + myid*counter + 1.123; END LOOP; OPITZ CONSULTING Kraków 2011 Strona 30
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=2011-01-11 ') FUJI1: (co 3 sekundy) # vmstat 3 10000 procs --cpu--- r b us sy id 1 0 1 0 99 0 0 2 0 97 0 0 1 0 98 0 0 2 1 97 0 0 1 0 99 FUJI2: (co 3 sekundy) # vmstat 3 10000 procs --cpu--- r b us sy id 0 0 1 1 98 0 0 2 0 98 0 0 2 1 97 0 0 1 1 98 0 0 2 1 98 Idle... FUJI1 FUJI2 OPITZ CONSULTING Kraków 2011 Strona 31
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) -------- ----------------------------------------------------------------------------------------------------------- 08: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=2011-01-11 09: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=2011-01-11 09: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=2011-01-11 09:27:45') FUJI1:(co 3sekundy) procs --cpu--- r b us sy id 73 0 100 0 0 70 0 100 0 0 71 0 100 0 0 70 0 100 0 0 70 0 100 0 0 73 0 100 0 0 FUJI2: (co 3 sekundy) procs --cpu--- r b us sy id 1 0 2 1 97 0 0 1 0 98 0 0 1 1 98 0 0 2 1 97 0 0 1 1 98 0 0 2 1 97 CPU load on FUJI1 1 FUJI1 FUJI2 OPITZ CONSULTING Kraków 2011 Strona 32
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 70 0 100 0 0 70 0 100 0 0 76 0 100 0 0 74 0 100 0 0 75 0 100 0 0 77 1 100 0 0 ESSEX OCI Client SCAN FUJI2 FUJI2: procs --cpu--- r b us sy id 0 0 2 1 97 0 0 1 1 98 3 0 12 1 87 11 0 79 1 20 16 0 99 1 0 17 0 100 0 0 SELECT INST_ID, (...) from gv$session where username = ESSEX ; INST_ID Username STATUS START_TIME lastcall[sec.ago] ---------- -------------------- -------------------- ------------ ---------------- - 1 ESSEX ACTIVE 11-01 09:29 41 1 ESSEX ACTIVE 11-01 09:29 41 1 ESSEX ACTIVE 11-01 09:29 43 1 ESSEX ACTIVE 11-01 09:29 43 2 ESSEX ACTIVE 11-01 09:29 39 2 ESSEX ACTIVE 11-01 09:29 39 2 ESSEX ACTIVE 11-01 09:29 39 2 ESSEX ACTIVE 11-01 09:29 39 2 ESSEX ACTIVE 11-01 09:29 40 2 ESSEX ACTIVE 11-01 09:29 40 2 ESSEX ACTIVE 11-01 09:29 40 2 ESSEX ACTIVE 11-01 09:29 41 2 ESSEX ACTIVE 11-01 09:29 41 2 ESSEX ACTIVE 11-01 09:29 42 2 ESSEX ACTIVE 11-01 09:29 42 2 ESSEX ACTIVE 11-01 09:29 43 2 ESSEX ACTIVE 11-01 09:29 43 2 ESSEX ACTIVE 11-01 09:29 44 2 ESSEX ACTIVE 11-01 09:29 44 2 ESSEX ACTIVE 11-01 09:29 44 OPITZ CONSULTING Kraków 2011 Strona 33
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) -------- ----------------------------------------------------------------------------------------------------------- 08: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=2011-01-11 09: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=2011-01-11 09: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=2011-01-11 09: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=2011-01-11 09: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=2011-01-11 09: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=2011-01-11 09: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=2011-01-11 09:25:15') Stable, idle.. OPITZ CONSULTING Kraków 2011 Strona 34
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=2011-01-11 10: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=2011-01-11 10: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=2011-01-11 10:24:17') CPU Load on FUJI1 (phase 1) FUJI1:(co 3sekundy) procs --cpu--- r b us sy id 0 0 1 0 98 0 0 2 1 97 44 1 15 4 80 71 0 99 1 0 70 0 100 0 0 72 0 100 0 0 70 0 100 0 0 FUJI2:(co 3sekundy) procs --cpu--- r b us sy id 0 0 2 1 98 0 0 2 1 98 0 0 1 0 98 0 0 2 1 97 0 0 2 1 97 2 0 1 1 98 0 0 2 0 97 CPU load on FUJI1 1 FUJI1 2 ESSEX OCI Client SCAN FUJI2 OPITZ CONSULTING Kraków 2011 Strona 35
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 70 0 100 0 0 0 0 2 1 97 71 0 100 0 0 0 0 2 0 98 71 0 100 0 0 1 0 3 0 96 73 0 100 0 0 7 0 50 1 50 84 0 99 1 0 6 0 74 0 26 84 0 100 0 0 6 0 75 0 24 85 0 100 0 0 6 0 73 0 26 SELECT INST_ID, (...) from gv$session where username = ESSEX ; INST_ID Username STATUS START_TIME lastcall[sec.ago] ------- -------------------- -------------------- ------------- ----------------- 1 ESSEX ACTIVE 11-01 10:26 72 1 ESSEX ACTIVE 11-01 10:26 72 1 ESSEX ACTIVE 11-01 10:26 73 1 ESSEX ACTIVE 11-01 10:26 73 1 ESSEX ACTIVE 11-01 10:26 73 1 ESSEX ACTIVE 11-01 10:26 73 1 ESSEX ACTIVE 11-01 10:26 74 1 ESSEX ACTIVE 11-01 10:26 74 1 ESSEX ACTIVE 11-01 10:26 75 1 ESSEX ACTIVE 11-01 10:26 75 1 ESSEX ACTIVE 11-01 10:26 75 1 ESSEX ACTIVE 11-01 10:26 76 1 ESSEX ACTIVE 11-01 10:26 76 1 ESSEX ACTIVE 11-01 10:26 76 2 ESSEX ACTIVE 11-01 10:26 74 2 ESSEX ACTIVE 11-01 10:26 74 2 ESSEX ACTIVE 11-01 10:26 75 2 ESSEX ACTIVE 11-01 10:26 76 2 ESSEX ACTIVE 11-01 10:26 76 2 ESSEX ACTIVE 11-01 10:26 76 OPITZ CONSULTING Kraków 2011 Strona 36
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 10.3.4 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
Kontakt Piotr Sajda Kierownik Service Engineering OPITZ CONSULTING Kraków piotr.sajda@opitz-consulting.com tel. +48 12 617 1810 tel. kom. +48 519 309 710 OPITZ CONSULTING Kraków 2011 Strona 38
Pytania/Odpowiedzi OPITZ CONSULTING Kraków 2011 Strona 39