Enterprise Production Deployment

customers supporting large user populations of 100 or more are primarily concerned with availability and load management rather than with minimizing hardware expense customers with more than 100 users should use this setup as a baseline and then add the equivalent amount of hardware for each additional 100 users the enterprise production deployment architecture splits into front end web servers back end processing servers the back end servers handle workflow, email processing, license allocation, inventory management, and so on this architecture also separates the production environment from development and testing there are two key advantages of separating development and testing from production any issues created during the development cycle do not affect production users you can perform upgrade testing on the development and testing servers before upgrading the production servers optionally, you can install your development and test landscapes onto separate physical servers example of in an enterprise deployment hardware requirements for the enterprise production deployment web servers the following are the hardware requirements for the web servers two virtual servers outside the firewall load balanced 4 cpu 16 gb memory 200 gb hard drive processing servers (production) the following are the hardware requirements for the processing servers used for the production landscape two virtual servers inside the firewall load balanced 4 cpu 16 gb memory 200 gb hard drive processing servers (development and testing) the following are the hardware requirements for the processing server used for the development (staging) and testing (uat) landscapes one physical or virtual server 2 cpu 4 gb memory 200 gb hard drive microsoft sql server requirements microsoft sql server is the database server for the deployment depending on your needs, you may have multiple database servers the following are the requirements for the microsoft sql server where the databases reside one physical server microsoft sql server microsoft sql server 2012 including management studio microsoft sql server 2012 sp2 including management studio microsoft sql server 2014 microsoft sql server 2016 microsoft sql server 2017 microsoft sql server 2019 inside the firewall 8 cpu 24 gb memory 1 tb hard drive customers may experience an error when always on availability is configured on the database server ivanti service manager currently does not support always on availability for more details, see ivanti community https //forums ivanti com/s/article/cannot push tenants over ops console error message failed to execute due to failed to sanitize database name in dbserver server name microsoft ssrs reporting server the reporting feature requires that microsoft sql server reporting services (ssrs) be installed and running on the database server that hosts the reporting feature microsoft ssrs can be installed on the microsoft sql server or on a separate microsoft ssrs server, depending on your preference we recommend a separate installation in the following situations multi tenant environments, including managed service providers and enterprises with multiple ivanti service manager tenants the microsoft sql database is used also for applications other than installations where the database server must remain online, because upgrading microsoft ssrs often requires a reboot the following are the requirements for the microsoft sql server reporting services (ssrs) reporting server one physical server microsoft sql server release 2016 inside the firewall 8 cpu 24 gb memory 1 tb hard drive hardware requirements when adding additional users for each additional 100 users, add this to architecture two additional web servers two additional processing servers system load determines the actual number of servers to add you can add the web and processing servers on demand in most cases, you do not need to add more development (staging) or testing (uat) servers high availability and load balancing you can achieve high availability through physical load balancing or by load balancing handled within for example, in the configuration shown in example of neurons for itsm in an enterprise deployment docid\ bhapgl 9cpnjelwecs8ll the ivanti service manager components are connected to one or more load balanced servers in this example the web servers, which contain components that are user facing, all connect to a physical load balancing server the process servers, which contain components that are not user facing, do not connect to a physical load balancing server, but instead use a built in load balancer the escalation engine, workflow engine, and email server have built in load balancing mechanisms the web servers and process servers all connect to the same ivanti service manager application database and configuration database high availability for the databases is achieved through a cluster communication within the system, such as between an process server and an web server, does not require ssl however, external communication can use ssl by default, the use ssl checkbox in all instances will be selected for new customers new customers must provide the fully qualified domain name for the server location in the ssl certificate field however, the use ssl checkbox is not selected by default for the existing customer, and they have to select use ssl if needed and provide the domain name for more details on the ssl certificate , see optional ssl configuration docid\ aei5nbqfmqwo5t3rabtex when using a hardware load balancer, turn on session persistence so that connections from the web browsers always get directed to the same web server about installing the neurons for itsm for the enterprise production deployment neurons for itsm components and databases in an enterprise deployment docid\ bhapgl 9cpnjelwecs8ll shows a diagram of the recommended locations of the various components components and databases in an enterprise deployment