1 Reply Latest reply on Mar 9, 2011 12:18 PM by dmshimself

    Scaling Out And TPS in the Technical Specs Guidelines


      I've been looking through the Technical Specs and Architecture Guidelines and have come across something that has confused me. When you look at the architecture guidelines, all the diagrams which show the Web and App servers separated out show the Webserver with IIS and Landesk Services. The app server just shows Landesk Services but no IIS. When looking further up the document you find this:


      2.2.6 LANDesk Services (TPS)

      LANDesk Services is the core application server of the LANDesk Service Desk suite of applications. It

      provides services in the way of programming interfaces in order to develop client applications that

      deliver LANDesk Service Desk functionality to users. The Services application server is deployed as

      either a web application hosted on Microsoft Internet Information Server (IIS) or as a set of DLLs as

      part of another server component. It provides a Web Services programming interface and a .NET

      programming interface for the development of applications. All LANDesk Service Desk applications

      use the features of LANDesk Services. Access to the LANDesk Service Desk database is provided

      through LANDesk Services (TPS).


      The above was taken from the Architecture and Technical Specs guide for 7.4 and so is the most up-to date I could find and appears to suggest that TPServices does not need IIS. This is contrary to any other information I could find on this site. The question is really, when you separate out (which we currently don't, we are currently running a unified web/app server with a separate db server and I'm investigating scaling out), does the app server need IIS and TPS installed, or does it not need either, or does it have some form of implementation of TPS without IIS as suggested above and if so, what is the mechanism by which this is accomplished?


      Alternatively it's possible that the document is in error and you only need the one IIS for the webserver and the App server connects into the Web server's TPS. If this is the case, what would people's thoughts be on installing a second instance of TPS/IIS on the APP server and using it as a load-balance/DR server if the primary web server becomes unavailable? You'd still lose self service, but with the TPS running you'd be able to use the console etc.


      Any thoughts on this would be appreciated, specifically around the seeming contradiction in the official documentation.


      Many Thanks,


      Anthony Mitchell

        • 1. Re: Scaling Out And TPS in the Technical Specs Guidelines

          You need IIS if you are going to run TPS on a server.


          But technically you don't need to run TPS on the same server as a windows service such as background service, is running on.  In very early deployments some years ago, the best practise was to have a single TPS running on a server somewhere and then the services would refer to and use that TPS in their config file.  However it was soon worked out that you got better performance by having more than one connection to the database (!).  Hence a TPS running on the apps server is now used to run those services as it's another thread into the database,performance improves and server dependencies are reduced.


          These days each web app such as webaccess tends to have it's own local TPS built into the code again for performance reasons, so you get the mutlithreading automatically, but then you still need IIS.


          What I think that bit of the document is referring is one of the LDSD APIs sets that are not generally available for commercial use.  You can run an external app which calls TPS functionality by having access to the right DLLS.  Such an external apps could be written in anything and just needs the right DLLS.  Those DLLS will call a web service which itself needs IIS, but the hosting app doesn't.  The DLLS and .exe files supplied as party of the Event Manager module is an example of this.


          Now turning to the last part of the question.  Really you should already have a separate TPS on the apps server to get the best performance.  I wouldn't recommend sharing that with anything else.  In an emergency you could run console connections through to this as well, but I'd stick to the apps server being dedicated to what it does and leave it as a small dedicated box.  I think from memory the guide recommends a tad too much memory for the apps server.  Single core and 2G is usually eprfectly OK for many app servers (IMHO!)


          If you can afford it Anthony, I'd first of all put webaccess out onto a different box if you are using it and then look at loadsharing between servers using load balancing.  The apps are multithreaded, so the more CPUs and memory you throw at them, the more they can handle, but having two servers that are truly independent is a wise move for any tier one app.