NetScaler case studies, TROFS update in 13.1 Build 37.38

Introduction

Wow, such a hook!

Ok, stay with me here. Things get added to the capability of the appliance and a lot of the time you have no context as to why that was added. Would it not be cool to have a write-up explaining what the problem was that needed fixing along with the use case?

Of course, it would.

The context would then offer some insight into how you could make use of that new option, this would then allow you to take another look at something that you might have been struggling with.

In this case, I would like to credit Michal Grabczyk and Lakshmi Prasanna Guru for getting this added!

What is TROFS?

Why would you do that?

The benefit of this is that the service status can be handed off to the web server team, they can set the TROFS code that then controls when a service is in the required state. They don’t need to raise a service ticket for whoever manages the NetScaler to do ‘something’. As they will know when patches or maintenance are needed on the web server itself. They just set the code, and the monitor sees it and stops sending new connections.

It is like they have a remote control for the NetScaler!

What is the problem with TROFS prior to 13.1.37.38?In this case, the customer was using this kind of setup.

The MPX was providing a front end for a Web tier that runs in a CDN. The details of the CDN are not significant. The customer was seeing intermittent 500 error responses from the NetScaler “Internal Server Error 43531”.

The NetScaler was set up as follows:

• SSL Vserver
• Autoscaling Service group using DNS.

In this case, the CDN was not able to change the behaviour as the sets of IPs are returned from the closest POP and those IPs are rotated for many reasons. However, when the IP address changes, it does not mean that the content is immediately unavailable under the old IP. Using those IP numbers is not desired and the delivery of the content is not guaranteed, it really is suboptimal. There is no way to “stabilize”/control the ip numbers returned by the CDN.

The solution in the new build

*• add servicegroup sg1 tcp ?

o -autoScale <autoScale> -memberPort <port> [-autoDisablegraceful ( YES | NO )] [-autoDisabledelay <secs>] [-autoTrofsGraceful ( YES | NO )]

• set servicegroup sg1 -autotrofsGraceful yes*

Internally every time a monitor is bound to the service group, the appliance stores the highest response time outs of the monitors in the servicegroup.

Depending upon whether TROFS graceful is enabled/disabled, the corresponding movement from UP-TROFS will be delayed by the max resptimeout/done immediately.

SummaryIn simple terms, this build adds some flexibility for the NetScaler to take account of changes in the infrastructure that it is fronting, in this case, that is hosted in a CDN.

Always handy to have some flexibility!

NetScaler rocks.