Service Manager 2016 with Cireson Analyst Portal - Infrastructure

Gerhard_Goossens

Good day everyone,

Sorry if this is a duplicate question...

We are in the process of implementing Service Manager 2016 with the Analyst portal.

My question relates the the amount of servers that will required and how we can scale up.

For some background:
We are a University with about 65000 students and 5500 staff.

For the first phase we will only import 50 users from AD with two support groups from different departments.

Once we are comfortable with how everything works we will scale up drastically. 

Attached is a structure on what I think will be needed.

My concern is the amount of analysts that will be connecting to the portal.

I know that if you use the SCSM console you can get about 10 connections per core on the Secondary servers and that you can load balance the secondary servers.

I'm unsure about the amount of analysts/users that can connect to the portal.

From what I have seen the portal is installed on one server that runs the cachebuilder service. So this will be the Secondary server.

Will we need more than one secondary server and if we do what tasks will be run on them. And what can we do for load balancing / disaster recovery?

I know I asked a lot of questions, but if we can take them on one by one it will be awesome.

Thanks in advance
Gerhard

Brian_Wiest

A lot of the design comes down to the amount of workflows you will have running in the end, also how you break out your console vs portal users. 
Looking at the pdf your SQL server looks like it might be a little weak. 
Example of our 2016 environment we are getting ready to stand up. (waiting for hardware to arrive from procurement)
Environment = 33k users, 1k analyst
Most our analysts use the portal as sole interface but about 25% use the Cireson Outlook plugin which count as console connections
We found that we get about 50 good console connections per server. 
The portal the math is about 100MB per active user in 24 hours
We currently have one portal server with the cache builder running at 32gb ram all day long no issue we are expanding thus why the below 2016 design is much bigger.
Orchestrator is its own farm

Our design (All are split between two farms for up-time requirements)(All connections handled via load balancer)
6 Management servers 
1 Workflow server (32gb ram) 
1 Fail over workflow server 
4 Console management servers
4 Portal servers 

For SQL 
Three node windows cluster
Service Manager cluster has 92GB memory allocation running on 1TB SSD
Data warehouse cluster has 66GB memory allocation

Brian_Wiest

A lot of the design comes down to the amount of workflows you will have running in the end, also how you break out your console vs portal users. 
Looking at the pdf your SQL server looks like it might be a little weak. 
Example of our 2016 environment we are getting ready to stand up. (waiting for hardware to arrive from procurement)
Environment = 33k users, 1k analyst
Most our analysts use the portal as sole interface but about 25% use the Cireson Outlook plugin which count as console connections
We found that we get about 50 good console connections per server. 
The portal the math is about 100MB per active user in 24 hours
We currently have one portal server with the cache builder running at 32gb ram all day long no issue we are expanding thus why the below 2016 design is much bigger.
Orchestrator is its own farm

Our design (All are split between two farms for up-time requirements)(All connections handled via load balancer)
6 Management servers 
1 Workflow server (32gb ram) 
1 Fail over workflow server 
4 Console management servers
4 Portal servers 

For SQL 
Three node windows cluster
Service Manager cluster has 92GB memory allocation running on 1TB SSD
Data warehouse cluster has 66GB memory allocation