Hi.
I'm migrating our TM1 10.2.2 applications to Planning Analytics Local (using only TM1 functionalities, no PAX or Workspace). Not usage also of TM1 Applications (eg. Contributor or Operation Console) but just TM1 Web functionalities.
Currently any Windows Server has each own Application Server installed locally to work with 1 or more TM1 Server on that machine. I'm thinking to set-up a dedicated Windows Server to install one Application Server (and BI for authentication) that will work with ALL the different TM1 Server spreaded in the different Windows Server and dis-install the "local" installed Application Server.
I'm mainly worried about the capacity of one unique Application Server to support all our users (more than 100).
Is it possible to install in one Windows Server more Application Servers? Is it a recommended solution? Any ones has experimented this configuration?
Thank you in advance for your comments.
Ottavio
Planning Analitics Local - Multiple Application Servers on same Windows Server
-
daniel.havassy
- Posts: 30
- Joined: Wed Sep 14, 2016 9:26 am
- OLAP Product: Planning Analytics Local
- Version: 2.0.4
- Excel Version: 2016
Re: Planning Analitics Local - Multiple Application Servers on same Windows Server
Hey Ottavio,
I think you're making the right choice with moving away from your single server installations to a distributed architecture. If my understanding is correct, you had many servers with installed and configured instances of Cognos BI, and all TM1 components.
If you are only using Cognos BI (Cognos Analytics) for security as your authentication provider, I'd say you should only have one instance of it and point your TM1 databases to use that instance.
As for TM1 web, you could theoretically have one single TM1 web instance installed and configured, with all your TM1 databases using it. Be mindful that with Planning Analyitcs 2.0.x we now have Websphere web servers, and it can only utilize 32 GB memory without you having to change the java vm settings so it can use more. Having said that, I would discourage you from using one "big" instance of the TM1 web server. It is indeed possible to have multiple TM1 web installations on the same windows server, but if you are planning that, I'd first think if it isn't worth going for the high availability configuration. I'm now in the middle of building a high availability TM1 web cluster and also have an open topic about it in this forum where I plan on submitting a summary once I'm done. But based on how heavy your TM1 web usage is, you might want to consider having a few virtual servers with TM1 web, working together behind a load balancer in a high availability set-up.
I think you're making the right choice with moving away from your single server installations to a distributed architecture. If my understanding is correct, you had many servers with installed and configured instances of Cognos BI, and all TM1 components.
If you are only using Cognos BI (Cognos Analytics) for security as your authentication provider, I'd say you should only have one instance of it and point your TM1 databases to use that instance.
As for TM1 web, you could theoretically have one single TM1 web instance installed and configured, with all your TM1 databases using it. Be mindful that with Planning Analyitcs 2.0.x we now have Websphere web servers, and it can only utilize 32 GB memory without you having to change the java vm settings so it can use more. Having said that, I would discourage you from using one "big" instance of the TM1 web server. It is indeed possible to have multiple TM1 web installations on the same windows server, but if you are planning that, I'd first think if it isn't worth going for the high availability configuration. I'm now in the middle of building a high availability TM1 web cluster and also have an open topic about it in this forum where I plan on submitting a summary once I'm done. But based on how heavy your TM1 web usage is, you might want to consider having a few virtual servers with TM1 web, working together behind a load balancer in a high availability set-up.