Jump to content
Welcome to our new Citrix community!

Content switching - multiple identical websites on 2 web servers


Recommended Posts

Let's assume we have two web servers hosting the same websites:

 

WebServer_01:

- website_A

- website_B

- website_C

 

WebServer_02:

- website_A

- website_B

- website_C

 

A simple Load Balancing setup would be:

- service svc_web01 - http:443 on WebServer_01

- service svc_web02 - http:443 on WebServer_02

- virtual server vs_web01 - http:443 balancing svc_web01 and svc_web02

 

But that is very basic and we prefer to utilize the NetScaler's capabilities for something more advanced.

We  would like to have monitors for each website and load balance the websites instead of the web servers.

For example:

- if website_A on WebServer_01 is down (or too busy) - the virtual server to redirect traffic to website_A on WebServer_02

- at the same time, if website_C on WebServer_02 is down (or too busy) - the virtual server to redirect traffic to website_C on WebServer_01

 

So, instead of monitoring and balancing at Layer 4, we are aiming at monitoring and balancing at Layer 7.

I understand we will need to use Content Switching but I wasn't able to find an article explaining this use case.

 

I would appreciate if somebody points me into the right direction:

- what kind of CS policy and what would it check

- how to monitor each website on each server

- how to tie all this.

 

 

Thank you,

Daniel

 

Link to comment
Share on other sites

First, while you said load balancing the web servers at the web server level and not per site is "very basic"; keep in mind its how most of our web load balancing is usually implemented.  We can still do app specific optimizations and security through a wide range of features such as content switching/cmp/caching/responder/rewrite without doing web app/web site level load balancing.  This actually isn't basic at all and is kind of fundamental to all the other stuff we can do.

 

Second, NS doesn't really load balance at the web app level without changing how you do load balancing.    Content switching alone doesn't help with this, though it might be used in conjunction with changing the lb solution. And the http-ecv monitor can help you track if a particular site is up or down and used individually or in combination with multiple monitors, but it all doesn't do what you want without changing your LB config.

 

 

Due to the way the netscaler defines services, the NS doesn't really load balance at the site level / web app level.  If you want to load balance the web sites independently of each other, you need to be willing to run your websites on different ports (or separate ips) so that it can treat sites independently up or down based on the service definition.

 

You could still use content switching if necessary to simplify the client side vip/port, but you still need separation at the service level.

 

Example 1:  traditional lb with a service on a singe ip:port

add service svc_web1 192.168.10.11 http 80

add serivce svc_web2 192.168.10.12 http 80

add lb vserver lb_vsrv_webstuff http <vip1> 80

bind lb vserver lb_vsrv_webstuff svc_web1

bind lb vserver lb_vsrv_webstuff svc_web2

 

In this case, as you've already seen, NS load balances the web servers regardless of which application path/site path you are accessing.  This actually is a pretty decent thing and doesn't have to be changed.  Load Balancing based on leastconnections, leastbandwidth or other is based on the total traffic sent to the web server by this lb vserver and not only a specific page/web app.

  • You can still use HTTP or HTTP-ECV monitors to monitor whether the server is function or specific sites are up or down to remove the service from usage.  If multiple monitors are bound, then any one will remove the service from use.
  • The problem, is we can't use this config to see that AppA is down on web1 and bypass AppA traffic to web1 while still using it for AppB, because the monitor downs the service for all traffic in this case.  Both AppA and AppB would have to bypass Web1.    (And most of the time this type of visibility isn't needed.)
  • For app specific optimizations, we can still use content switching/responder/rewrite to apply policies to specific webapps based on path even if the service is looking at the server as a whole.  

Load balancing would work for multiple web sites on svc_web1 or svc_web2. While you can use monitor to monitor a specific site, when it fails, the service is down for all web sites, not just one.   Multiple web apps can still be load balanced and the load could take into account all activity across sites by viewing the web server as a whole.

 

But in this case, you wouldn't have the ability to send detect that WebAppA is down on svc_web1 and still load balance WebAppB across svc_web1 or svc_web2.  

 

Example 2:  Load Balancing web apps individually on the same destination web servers....

If you wanted to load balance two web servers, but distribute traffic per web app independently so that if WebAppA is off on server Web1 and it goes to server Web2 only; while WebAppB can be load balanced to both Web1 and Web2, then you would have to run the web apps on different ports (or even IPs), so they can be load balanced as independent services.

AppA: 

add service svc_web1_appA 192.168.10.11 http 81

   bind service svc_web1_appA mon_appA_httpecv ...

add service svc_web2_appA 192.168.10.11 http 81

   bind service svc_web2_appA mon_appA_httpecv ...

add lb vserver lb_vsrv_appA http <vip1> 80 

bind lb vserver lb_vsrv_appA svc_web1_appA

bind lb vserver lb_vsrv_appA svc_web2_appA

 

AppB

add service svc_web1_appB 192.168.10.11 http 82

   bind service svc_web1_appB mon_appB_httpecv ...

add service svc_web2_appB 192.168.10.11 http 82

   bind service svc_web2_appB mon_appB_httpecv ...

add lb vserver lb_vsrv_appB http <vip2> 80    # either different VIPs or different ports are needed; i went with vips

bind lb vserver lb_vsrv_appB svc_web1_appB

bind lb vserver lb_vsrv_appB svc_web2_appB

 

NOTE: I ran the services on different ports; while keeping the LB vservers on different VIPs and port 80. CS could be used in this case to simplify the vip:port handling as well. (There are several variations.)  But CS alone doesn't make Example 1 into Example 2; you have to change your load balancing approach to do app level load balancing.

 

In this case, if mon_appB_httpecv fails on svc_web1_appB, then the WebAppB traffic should use svc_web2_appB only.

While AppA could still load balance to svc_web1_appA and svc_web2_appA independently. (Assuming the issue with WebAppB on the web1 server is site specific, like a maintenance event, and not a full server outtage).

 

However, load balancing in this example, would only take into account connections per specific web app and not all connections to the web server.

 

 

 

 

 

 

Link to comment
Share on other sites

  • 5 months later...
On 3/4/2019 at 10:37 PM, Rhonda Rowland1709152125 said:

then you would have to run the web apps on different ports (or even IPs),

 

You do not need to run them on different ports or IPs.  You just need site or app specific monitors attached to services or service groups with the same servers in them.  Each service or service group gets a non-addressable LB, and they are brought together under a single IP with a content switch that uses policies to direct each specific site or app to the service or service group for that app.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...