- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-24-2008 12:16 PM
Infrastructure for Hyperion needs to support users (approx 200), as defined by business, across different product components of Hyperion Suite. In order to support this load across different product components, two VIPs with load balancing across different ports Apart from balance of load, session persistence need to be maintained with an idle timeout.Hyperion components would be interacting between VIPs as well and sessions need to be persisted across vips as well.
How do we maintain VIP to VIP session states when on the same CSS?
Solved! Go to Solution.
- Labels:
-
Application Networking
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-24-2008 01:00 PM
If the serverfarms served by two VIPs are layer 3 seperated (ie each serverfarm is on its own network) then you can simply LB the client to tier1 , tier 1 to tier 2, and tier 2 to tier 3 and so on ...
If server farms belonging th the two VIPs are L2 adjacent (share the same L3 network)
then..
You will need to use Source NAT the
traffic as it hits the VIP. This ensure that when VIP1 servers initiate connection to VIP2 the return traffic is not handed by VIP2 servers to VIP1 servers directly.
Probably this flow will explain this scenario
Lets suppose VIP1 (192.168.1.1) servers are 10.10.10.1 & 2
VIP2(192.168.1.2) servers are 10.10.10.100 & 10.10.10.200
1. client 1.1.1.1 hits VIP1 (192.168.1.1) CSS selects a real (10.10.10.1) and sends the client request to the real server.
2. Now If VIP1 real (10.10.10.1) initiate a conn to VIP2 (192.168.1.2) the CSS will select a real from VIP2 serverfarm (10.10.10.100) and forward the traffic to this real (10.10.10.100). This Vip2 real will see source ip of this request initiated from VIP1 real (10.10.10.1) and hence will send the return traffic directly to 10.10.10.1.
Vip1 real server will not accept this conn as it never intiated a conn to 10.10.10.100.
The simplest workaround would be to enable source nat such that when VIP1's real initiate conn to VIP2 the CSS should change the source ip to its own IP before forwarding the client request to VIP2 real.
Hope it make sense..
Syed
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-24-2008 01:00 PM
If the serverfarms served by two VIPs are layer 3 seperated (ie each serverfarm is on its own network) then you can simply LB the client to tier1 , tier 1 to tier 2, and tier 2 to tier 3 and so on ...
If server farms belonging th the two VIPs are L2 adjacent (share the same L3 network)
then..
You will need to use Source NAT the
traffic as it hits the VIP. This ensure that when VIP1 servers initiate connection to VIP2 the return traffic is not handed by VIP2 servers to VIP1 servers directly.
Probably this flow will explain this scenario
Lets suppose VIP1 (192.168.1.1) servers are 10.10.10.1 & 2
VIP2(192.168.1.2) servers are 10.10.10.100 & 10.10.10.200
1. client 1.1.1.1 hits VIP1 (192.168.1.1) CSS selects a real (10.10.10.1) and sends the client request to the real server.
2. Now If VIP1 real (10.10.10.1) initiate a conn to VIP2 (192.168.1.2) the CSS will select a real from VIP2 serverfarm (10.10.10.100) and forward the traffic to this real (10.10.10.100). This Vip2 real will see source ip of this request initiated from VIP1 real (10.10.10.1) and hence will send the return traffic directly to 10.10.10.1.
Vip1 real server will not accept this conn as it never intiated a conn to 10.10.10.100.
The simplest workaround would be to enable source nat such that when VIP1's real initiate conn to VIP2 the CSS should change the source ip to its own IP before forwarding the client request to VIP2 real.
Hope it make sense..
Syed
