Skip to main content

Search

Welcome to Tibero GTS!

How to Evenly Distribute Sessions When Connecting Through TAC Environment WAS

Document Type | Technical Information

Category | Interface/Integration 

Applicable Product Versions | Tibero5, Tibero6, Tibero7

Document Number | TIITI057

 

Overview

This document describes how to evenly maintain the number of sessions connected from WAS (Web Application Server) to each TAC node in a 2-node TAC environment.

 

 

Method

TAC Session Even Distribution

A 2-node Tibero Active Cluster (hereafter: TAC) is an Active-Active structure where all nodes can perform Read/Write operations.

In a 2-node TAC environment, each node's Tibero Cluster Manager (hereafter: CM) can activate VIPs.

In WAS, depending on how the 2-node TAC is connected, an even session distribution can be configured.

If even session distribution is not considered, sessions may concentrate on one node.

 

 

TAC Connection URL

Note

tbJDBC Connection URL Manual

If the Connection URL in the TAC environment is set as follows, sessions will not be evenly distributed.

In the TAC environment, setting the options failover=off and load_balance=off enables even session distribution between WAS and TAC.

jdbc:tibero:thin:@(description=(failover=on)(load_balance=on)
(address_list=(address=(host=192.168.100.101)(port=8629))
(address=(host=192.168.100.102)(port=8629)))
(DATABASE_NAME=testdb))

 

TAC Session Unbalance

When failover=on and load_balance=off are used in the JDBC Connection URL of WAS, sessions may concentrate on one side, failing to maintain balance.

1. Situation where TAC nodes 1 and 2 are started, then WAS nodes 1 and 2 are started sequentially

  • WAS node 1 first looks at VIP1 of TAC node 1 and connects to VIP2 if no response is received.
  • WAS node 2 first looks at VIP2 of TAC node 2 and connects to VIP1 if no response is received.

 

2. Situation where VIP1 fails over to TAC node 2 due to failure of TAC node 1

  • VIP1 of TAC node 1 has failed over to TAC node 2.

  • All sessions connected to VIP1 of TAC node 1 are disconnected.

  • When new session requests occur on WAS1 during the VIP1 failover, connections are made to VIP2 due to failover=on setting.

 

3. Situation after VIP1 failover to TAC node 2 is completed

  • VIP1 failover to TAC node 2 has been completed.

  • During the failover process, sessions connected to WAS1 are connected to VIP2.

  • Once VIP1 failover to TAC node 2 is complete, sessions connected to WAS1 are connected to VIP1.

  • In this situation, session connections to VIP1 and VIP2 may not be evenly maintained.

 

4. Situation where TAC node 1 recovers and VIP1 fails back to TAC node 1

  • VIP1 fails back to TAC node 1.

  • All sessions connected to VIP1 on WAS1 are disconnected.

  • As in situation โ€œ3,โ€ new connection requests on WAS1 during VIP1 failback connect to VIP2 due to failover=on setting.

  • This may cause session concentration on VIP2 when TAC node 1 restarts.

 

5. Situation after TAC node 1 recovers and VIP1 failback is completed

  • VIP1 is activated on TAC node 1.

  • During VIP1 failback, sessions connected to WAS1 remain connected to VIP2.

  • After VIP1 failback completes, sessions connected to WAS1 are connected to VIP1.

  • Ultimately, more sessions accumulate on VIP2 than VIP1, and unless the WAS Connection Pool is restarted, sessions connected to VIP2 through WAS1 will not return to VIP1.

 

TAC Session Balance

  • Set only TAC node 1 VIP in the Connection URL of WAS1.
    • failover=off and load_balance=off
    • Set or remove the above two options (default off)
  • Set only TAC node 2 VIP in the Connection URL of WAS2.
    • failover=off and load_balance=off
    • Set or remove the above two options (default off)

 

1. Situation where TAC nodes 1 and 2 are started, then WAS nodes 1 and 2 are started sequentially

  • WAS node 1 only uses VIP1 of TAC node 1 as the connection target.

  • WAS node 2 only uses VIP2 of TAC node 2 as the connection target.

  • VIPs of TAC fail over to the opposite node if a node goes down.

 

2. Situation where VIP1 fails over to TAC node 2 due to failure of TAC node 1

  • VIP1 of TAC node 1 fails over to TAC node 2.

  • All sessions connected to VIP1 of TAC node 1 are disconnected.

  • Then, it waits for VIP1 to be activated on TAC node 2.

 

3. Situation after VIP1 failover to TAC node 2 is completed

  • VIP1 failover to TAC node 2 has been completed.

  • From the moment VIP1 failover to TAC node 2 is complete, WAS1 sessions connect to VIP1.

  • WAS1 sessions do not connect to VIP2 of TAC node 2.

  • Even if TAC node 1 is down, sessions operate as intended through VIP1 and VIP2.

 

4. Situation where TAC node 1 recovers and VIP1 fails back to TAC node 1

  • VIP1 fails back to TAC node 1.
  • All sessions connected to VIP1 on WAS1 are disconnected.
  • WAS1 sessions wait for VIP1 to be activated on TAC node 1.

 

5. Situation after TAC node 1 recovers and VIP1 failback is completed

  • VIP1 is activated on TAC node 1.

  • After VIP1 failback completes, WAS1 sessions connect to VIP1.

  • Ultimately, even if the database restarts, sessions on WAS1 and WAS2 can be used evenly as intended.

 

Conclusion

The JDBC Connection URL of WAS is set by the WAS engineer.

If sessions are not evenly distributed across WAS in the customer environment, sessions can be evenly distributed through TAC VIP FAIL-OVER / FAIL-BACK.

This document only covers session connections by WAS and does not cover separate application modules or other solution connections.

 

 

Related to