MID Server Optimization

[Mansor2]

Hello all,

We have a cusomter who has 18 data centres in total. They're all in different locations within the region. we have scoped around:

PROD = 36 MID servers (VMs)

TEST = 18

DEV = 18 

following the best practices model. Customer feels it is bit too much or how to optimize the number of MID servers to cater thier requirement. 

Is there any way we can optimize the count of MID servers that anyone can share some light on? 

I had tried to  group data centers into tiers based on size, complexity, and network segmentation. (e.g., Tier 1 - Large & Complex, Tier 2 - Medium & Moderately Complex, Tier 3 - Small & Less Complex). is this a good approach?

Will PROD need HA setup event though it could be small in size? is it a must? 

Any help woulb be great. any experience you can share will make a prgoress. 

Regards

Mansor

[Kieran Anson · Accepted solution]

Without knowing more about the 18 data centers (size, complexity, infra types) it's hard to say. MID server scaling and optimisation is such a niche and trial and error situation.

However some theoretical scenarios

Are all the DC's of equivalent business criticality? If some are DR sites, it could be practical to not have redundancy in place and only have one MID server. Equally if multiple sites are DR sites, you may only need one MID server for all of those sites. 

Regionally how close are these DC's and what level of inter-connectivity is in place? if the organisation has a concept of availability zones (clustered DRs) you could have a MID-cluster set to scan multiple DCs

Investigate what the concern around the quantity is from the customer? Is it cost? Is it licensing (of the underlining VM)?

Linux MIDs or even K8s can be utilised for non Windows infrastructure and are generally cheaper. Multiple MID agents can also be deployed on the same VM if the customer has other redundancies in place at the hypervisor level.

A lot of organisations have shared-services VMs. These are VMs which have multiple services running for less mission critical work. MID agents could be deployed on these VMs instead of a dedicated VM.

What capacity, environment, and config policies are in place in the business? Dev & Test may both be considered sub-prod rather than separate, distinct, environments and rather than having 18 + 18 VMs, you just have 18 VMs with 2 MID agents deployed on each.

[Mansor2]

Thanks, Kieran. at this point not much is provided by the customer. Not all are critical, some could be server rooms is my understanding and could be DRs as well. 

regionally they're pretty much within the country within one city I would say. 

I believe the concern is the cost and licensing. Customer wants to use only Wiindows for thier own reasons. 

Shared services VM seems a good option for now to take back to them. 

are you saying for sub-prods can use 1 VM instead?

customer wants High-availaibity, shouldn't that be 36 for PROD and 1 each for sub-prods? can you please explain your last paragraph? we have no clue on the policies they run at this stage. 

[Kieran Anson]

It sounds like you're still missing a lot of factors that would aid in a good answer, and your initial estimate is a bloated and scared them.

Using an example from a previous implementation, a customer had 2 DCs (1 being a DR site) and the other 11 discovery locations were branch offices. Because these were all geographically local (same country) and the client had an impressive SD-Wan setup back to the DC's only 2 MID servers were needed. 

In regards to my last paragraph, your dev and test environments aren't going to be continuously scanning the entire network domain like prod, so you don't need the same capacity. Depending on the company policy, the sub-prod environment may not even be allowed to access prod-level infrastructure. So test and dev need a very finite amount of MIDs in order to discover infra. You can also place both a dev and a test mid agent on the same VM as your sub-prod environments shouldn't (really) have their schedules active, unless for testing or active sprint development