Recently at work we have been doing some load testing and finally realized that we needed to load balance the AppSense Personalization servers in our environment. Prior to this we have just utilized the standard AppSense failover method. We needed something a little more robust. These were the requirements.
Solution must be able to distribute the load among all of the AppSense Personalization servers
We didn’t require that each Personalization server have an exact equal load. We just needed to make sure that the load was distributed among them without one taking all of the work.
Solution must be able to detect when a Personalization server was unavailable and take it out of the list of available servers.
Simply stated, if a server was unable to serve the Personalization role we needed it removed so no further connections were created until it was functioning again.
Determine How to Monitor Availability
Before I configured anything I needed to determine method I would use to detect that the Personalization server was actually functioning. Probably the first two things that come to mind would be a TCP monitor on port 80 or an http monitor. Neither of these monitors would be acceptable.
I didn’t just want to know if IIS was still running. I wanted to know if Personalization was working. We have had several cases where something caused application crashes which then caused the PersonalizationServerPool to crash enough times to trigger the application pool’s “Rapid-Fail Protection”. In this case IIS and thus http was still functional so those checks would still register successful.
I was then reminded by our AppSense channel partner about the status page who just happened to be in our office that day.
On your Personalization server at http://Server:Port/PersonalizationServer/status.aspx is a dynamic status page that you can use to get information about your client and Personalization server.
For this page to return any data Personalization needs to be running so I decided to use it for my test. I just need some text to synchronize the test on and “Successfully connected to the profile server status handler” seemed fitting so I decided to use that.
Configuring the NetScaler
Setting up the Monitor
Now I am ready to do some dirty work. I logged into my NetScaler and navigated to the Load Balancing node and then to Monitors. I created a new monitor named MON-AppSense. You are going to use the HTTP-ECV monitor type.
Leave the Destination IP and Destination Port blank. This allows the NetScaler to insert the servers information into those fields. This enables you to use the monitor on all of your Personalization servers.
The first five fields on your left side determine how often you will probe your server and how you will react to changes. These values are going to be dependent on your environment and I recommend you sitting back for a couple of minutes to think about your values.
- Interval. The time interval between probes sent to a server. The value must be greater than the value entered for the response time-out. The value is set in seconds.
- Response Time-out. The time the monitor waits for the response from the server. The value must be less than the monitoring interval. The value is set in seconds.
- Down Time. The time interval before the next probe after a server is marked DOWN. The value is set in seconds.
- Deviation. Deviation from the learned response time for Dynamic Response Time monitoring. The maximum value in seconds is 159 and 159000 in msec. The minimum value is 10 msec. Minimum value: 1, Maximum Value: 2147483647.
- Retries. The number of consecutive probes failures after which the appliance determines the service as DOWN. The default value is 3. The minimum value for this parameter is 3 and maximum value is 127.
The Special Parameters tab is where you put in the URL and the string you are expecting to get back if the service is up. You are directing NetScaler to get the /PersonalizationServer/status.aspx page and expect to see “Successfully connected to the profile server status handler” somewhere in the data that is sent back to that request.
Now you just need to go into each of the Services for the Personalization server and attach the monitor to the Service
Configuring Load Balancing
Now you are ready to configure the actual load balancing for the Personalization servers in the Virtual Server section. The key parameters for this step are the Load Balancing Method and the Persistence.
The Load Balancing Method is the method which the NetScaler distributes connections to the individual Personalization servers. I decided to use the “Least Connection” method, which is the default. I am not a networking guru so I am not going to say that is the absolute best choice. But I did some load testing afterwards and was satisfied with the results.
This method will work especially well if we do encounter a failure. The NetScaler will monitor the connections to the servers and maintain an even connection count. For my load testing I took one of the servers out of rotation. The other server took up the slack with perfection. When I re-added the original server the connections were again balanced.
The persistence is what determines how the NetScaler determines where to send connections so that subsequent requests are sent to the appropriate server. For Personalization each request contains all of the necessary information for that transaction. In other words there are no “sessions” created for each transaction. This may sound strange, but trust me. I did a full load test after implementing this change and did not encounter any issues with users not receiving or submitting their personalization settings.
As always I welcome all of your comments and questions.
idea what I was getting into nor the amount of work it was going to entail. It was a very long and detailed process, but I can finally say it was all absolutely worth it.
