ServiceDesk

Ok, we are about ready to go live, and the plan is to have 2 WF/SD servers and load balance them.  Does anyone have any experience or tips on configuring things properly?

We are using a load balancing appliance, which is setup. Its the install of WF/SD on each server is what I'm unsure about.

What you would want to do, is publish the workflows to both WF servers. Then, in the application properties, you would want to change the variables to point to the load balanced DNS name, instead of the specific server. You would want to do this for each of the ITIL processes that you are using (Incident Management, Problem Management, Change Management, Release Management).

Hope this helps,

 David Ramazetti

 Senior Technical Solutions Consultant

 XCEND Group

Only problem with that idea is they will point to 2 different databases, which may or may not work for everyone.  I have tried it that way and that was what i ran into, which in our case wouldnt work.

To have shared data it looks like you have to change the exchange connectors ( and most of us don't have a license to do that, so you have to have Symantec give you a temp key or something )...  Since I posted this there was a document published on how to do it, and its rather convoluted but doable. Tho it looks like you still have to recreate the portal maually for each install.

What I did was have 3 servers - two on the front end that handle all user requests, and one on the back end that handles time outs and escalations, and scheduled events.

 

The two front end servers are the only ones that are in the VIP on the load balnacer, the back end one should never have a client connected to it. On the front end servers you should have the Do Not Process Timeouts and Escalations checked, and under Workflow Server Configuration, Edit the Auto Trigger Info and Uncheck the Run WebServices. This will prevent the scheduled tasks from executing.

 

Lastly on backend server you'll need to modify the HOSTS file. Set the local IP address of the server to the DNS name of the VIP. This way any tasks will have the proper URL in them (which should be the URL of the VIP).

 

This works for Workflow in general, should also work for SD, but YMMV. The downside is the single point of failure is the backend server, tho rebuilding it if it fails is not all that hard.

 

rob

 

 

 

That was sort of the plan we were going to do as well, and i agree not being able to cluster the backend workflow server is a bad thing if you need to provide guaranteed up-time to your customers. Even if you cluster SQL you still run the risk of extended outage as you rebuild the WF server.

But we are going in a different direction now, so its sort of moot for us. I am curious how you propagated your portal settings between the separate front end servers ,and how you dealt with users with different GUIDs across the different portal servers.

We tackle that in 2 ways. the back end is Virtual, so rebuilding is rather simple - we can just roll back to the previous backup and republish whatever is missing.

The other way is to have a second back end server, configured just like the primary, but have the timeouts and escalations turned off, and also turn off the Run Web Services. If the primary fails, all you would have to do is enable those 2 options and you back in business.

 

As for users, not sure what you mean by this. The Process Manager Database holds all the information regarding users, and it's a separate database on a separate server. All the users reside in that DB,so there are no duplicates since there is only one DB. We also are using a db for the message data, so no duplication there either. 

Like I said, this works for Workflow in general, you may have to make some adjustments for SD, but I have to imagine it's possible, especially if you have a few hundred workers and several thousand users submitting tickets - you would need a load balancer somewhere!

 

rob