Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

ServiceDesk 7.5 behind F5 hardware load balancer

Created: 05 Sep 2013 | 15 comments

I've asked this question about 20 months ago and didn't really get any responses so with 7.5 being out I thought I'd ask again. I understand the concepts and the instructions behind clustering ServiceDesk 7.5 and they make sense. What we'd like to do involves a hardware load balancer but no cluster so that we can use what we like to call service names rather than server names. We'd also like to offload SSL to the F5 Big-IP load balancers that we have in the datacenter.

If I understand the instructions correctly, this should work:

Clients connect to a service name, let's say https://servicedesk.something.com. This points to the LB. There we would drop SSL (wildcard cert on the F5 allows complete acceptance by clients, which is handy) and direct to a VIP. This VIP then points to the actual servicedesk server. In theory this should all work if the instructions in the documentation are accurate, is this correct? If this is right, then when we install SD, is it smarter to use the VIP IP address as where servicedesk is located or the VIP name? We wouldn't use servicedesk.something.com as this could change and would be designed to, is that a correct assumption?  I also assume that I'd have to change the URLs inside of SD so that when emails go out with links, they aren't populating with the VIP, which isn't accessible from the front-end, but rather with the public-facing name? Can someone point me to where the best places are to do this?

 

Hopefully someone out there has done this or seomthing similar, even if it isn't with an F5. Would love to get this going in the next couple of weeks.

 

 

Operating Systems:

Comments 15 CommentsJump to latest comment

Lark's picture

I have a similar setup with one of my customers - SD 7.5 load balanced behind a f5.  We don't have a requirement for SSL (yet) so we're not using that offload feature of the f5.

If the alias servicedesk.something.com is going to change then you need to make sure what ever name you give SD when you install isn't going to change.  In my experience things start breaking in SD no matter how many places you find and replace.

The advice I have recieved from backline support is not to change any of the links within ServiceDesk.

jpellet2's picture

That's mostly what I thought but I don't understand what names/IPs to use during installation. When SD asks for the URL or IP I would use the internal VIP according to instructions but then when links get sent to customers via email won't those links be of the internal VIP and not the external URL? That internal IP or name is not accessible from any external source.

Lark's picture

You need to enter alias or IP that anyone who will be accessing ServiceDesk can use.  Normally I'd expect that to be the alias that dns resolves to your virtual IP.  By the sound of it neither of these will work for you.

Can you explain what you mean by external source?

jmankin's picture

During install you want to use the VIP DNS name https://servicedesk.something.com. My installation sits behind a F5. I'm not tracking with what your asking about SSL offload. We are using SSL in our enviornment. This is my installation at a high level and I apologize for the shorthand, this is a memory dump because im at home and i dont have my documentation in front of me.  If i lose you just leave a comment and I can answer you tomorrow.

  1. IIS installed on both SD nodes and Cert installed for SSL
  2. static DNS entry created for ServiceDesk URL. This is the VIP DNS
  3. run setspn if using kerberos for auth. service account and http://servicedesk.something.com
  4. add delegation to AD account if using kerberos
  5. Both nodes added to F5 pool. We started with web services template
  6. Shutdown/Power Off one of the SD servers. Make sure F5 sees the node unavailable.
  7. Install SD and where prompted add the VIP DNS URL. https://servicedesk.something.com
  8. Post installation. Change the Process Manager Sessions to SQL storage. Change deployment IP address to local address. Change app pools and workflow service to use your service accounts
  9. test logon from https://servicedesk.something.com
  10. Shutdown 1st server
  11. make sure F5 sees it down
  12. install SD on Node 2 and where prompted add the VIP DNS URL and point this install to the DB instance that you set in the first server install.
  13. Post installation. Follow step 8 above and also set this server not to process escalations or timeouts.
  14. reboot and bring up node 1. if all is good your load balanced using the F5.

 

 

jpellet2's picture

I should draw this out and perhaps will a little later on. I understand how to setup the server, the issue and confusion comes in from the F5 but I think I have it now.

The confusion comes down to our use of cnames and aliases and I can now deal with that as long as I name the VIP appropriately. As for SSL, we can offload the SSL onto the F5, allowing it to do the processing of the decryption and pass non-ssl traffic back to the host. I believe this is how we'll do it (at least try it), this allows us to use the F5 with an installed digicert wilcard certificate for our web domain and then forward traffic through the VIP back to the SD server over port 80.

All a bit confusing but it won't take long to test I suppose.

jpellet2's picture

Here's where I'm at. The F5 is configured and the VIP is forwarding to the server like I'd expect. I start the install of SD 7.5 MP1 and can get through the Workflow installation. This is where things go wrong it seems. During the installation it asked for the URL which I provided the VIP address. The workflow server installed and I can actually get to a login page from the server and from off-server to the VIP. However, when I go to try to run the SD install I am not being allowed because the "Workflow Server to ProcessManager Portal Connection" fails. Anyone know what I might be doing wrong? Should I do the workflow server install with the local machine name instead?

jpellet2's picture

Local System but I wonder, based on some of the settings for the Process Manager, that this should be a domain service account. Especially when you need to enter your SQL connection information and if I choose Windows that works...while I'm logged in. If I'm not I imagine that that wouldn't work.

Lark's picture

To fix the "Workflow Server to ProcessManager Portal Connection" issue:

  1. In the Start menu, select Start > All Programs > Symantec > Workflow > Workflow Designer > Tools > LocalMachineInfo Editor
  2. In the Servers list, ensure (local) is selected and click the Edit button to the right
  3. Change the IP Address field to 127.0.0.1 and OK your way out of there
  4. Restart the “Symantec Workflow Server” service

Then try the SD install part again

jpellet2's picture

That certainyl got me further. It allowed me to install SD.

jpellet2's picture

So I was able to install SD and was walking through the steps Load Balancing ServiceDesk documentation. I made it through and when I tried to log in to ProcessManager I now get "The Request Failed with an Empty Response". One part of the instructions tell me to enter my SQL connection information and when I choose Windows it will work but how would that work if I was not logged in? Would the service need to run as a Windows domain account or should I create a SQL account to run it as? I don't think that has any bearing on the error I'm getting right now, however, since I am logged in, can successfully connect to the DB and am getting that error.

 

Of course I just realized that the app pools are running as the service account so that might allow the sql connection to remain persistent? In any case, there is still the empty reposnse I am dealing with.

jpellet2's picture

Interesting happenings now. Once I used Lark's info I was able to install SD but after configuring the sessions to be stored in SQL I couldn't get anything to work. I re-ran the config checker and once again I ProcessManager was not able to communicate with the workflow server. In the logs it also appears that the machine is trying to log in and not a user account so that could be the issue, not 100% there.

jpellet2's picture

Perhaps this issue has to do with needing to access the server with both forward and reverse lookups? Going forward we can access the URL by the VIP and log in, however when we log in all of the reports have errors on them. (Accessing the server locally or by the actual server IP works as it should). This is all before enabling SQL Sessions. If we do that, nothing works.

But, when we look at this from an IP point of view, we can do a forward lookup as expected but the reverse lookup goes back the the F5's group or pool VIP of internal-vip rather than the IP set for this server specifically. Might this have any baring on the issue? I've submitted a case for support so perhaps they will be able to shed more light on this.

Lark's picture

Something the load balancing doc omits is that SQL User based auth to the SQL server should be used.  This was the advice I recieved from Symantec support.  Even if you are only using a single SD server it would be worth doing this if there is even a small chance that you'll want to scale out in the future.

Another thing I have noticed is that the ServiceDesk part of the install isn't 100% consistent.  You should pay close attention to the installation log, even if the install appears successful.  Look for any errors and investigate.

jpellet2's picture

I've looked at this and had support look at this and it appears what I want to do simply won't work, at least that's what I'm being told. Of course I don't see why not exactly but I will now have to pursue an alternative.  What I am told is that I can't set a single node up to be load balanced even though there isn't a second machine. It doesn't make sense why not since all we are really doing is moving sessions to SQL and the setup would/should work as if one node were off-line but that's what I was told.

 

to recap, what I was hoping to do was have https://sd.com come in through the F5 which is the VIP. It terminates SSL at the F5 so then a straight port 80 connection goes from the F5 to the server (one configred for load balancing, although the only one in the cluster.) as http://sd.com but points to the server name which may be sd-prod-1.com. There Servicedesk gets installed with the client-facing URL being sd.com but localmachineInfo pointing to 127.0.0.1. When this is all done, and the logs verified that nothing went wrong during installation, all SOAP responses are returned empty.

I might try one more thing since it makes no sense to me why I couldn't set up a single node by itself but if that doesn't work I will have to pursue trying to use an alias but I'll start another thread for that mess.