MID Server Administration in 2022

in

My second most popular blog article since founding this blog was “Best Practices: MID Server Administration”, and while I think it has aged well, things are ever changing. I won’t be rehashing everything again, just where I think some updates are needed!

  1. Basics

    a. Sizing / Server Specs

    MID Servers have gotten more resource intensive over recent years, some newer applications (ACC, CPG, EM) are being recommended to add more CPU (now up to 8 core), and more memory (8gb normal, 16 on the high end). I’ve also seen some Discovery Patterns like Kubernetes chug with 4 core CPU and 6 GB dedicated wrapper memory - but it’s very dependent on the scale of discovery. I would recommend a base load out in Production with 8 Core CPU, 12 GB RAM, 60GB Disk, and updating the MID Server config to leverage more than 25 threads, and 6GB or more of usable RAM. You might be able to get away with less for Orchestration, and you’ll need more for specialized cases like ACC.

    b. Multiple Services on a Single Server

    It’s possible to install the MID Server and run it multiple times on the same physical/virtual server. For sub productions this is an amazing way to scale to add additional MID Server services, while maximizing Server resources. I think the practice makes a lot of sense in certain situations, but there are some key limitations. MID Servers can interfere with each other and cause resource spikes, they will compete for network bandwidth directly, and they can make issues harder to debug. I would stick to only using these in subprod, and regardless how beefed up the server is, I wouldn’t go any higher than 3 services running on the same box.

  2. Counts - How Many?

    a. MID Server Calculator / Discovery Estimator

    ServiceNow provides a worksheet to go through and calculate based on how many devices (servers, routers, switches, storage arrays, load balancers) you have, and how often you need the discovery data refreshed. If you have 10k servers, but only need them discovered weekly over the weekend, then you can get away with fewer MID servers. If you need them discovered daily, but can only discover them at night, to reduce system load, then you need a much higher number of MID servers. There are definitely companies out there that have over 100 production MID servers to handle such large amounts of infrastructure and time requirements.

    b. Redundancy

    Besides having enough MID servers to do the job, the next level of maturity is introducing redundancy measures. If most of your MID servers are in a single data center, and that goes down, you need a backup plan. There should be multiple redundant servers in different data centers and for different use cases like orchestration and discovery.

  3. Time Sliced Usage

    To make the most out of your MID server, it is important to think about spreading out the load, both across multiple MID servers, as well as spreading it out along the timeline. Most people are familiar configuring discovery schedules, but it is also important to think about this in the sense for other applications as well, to try and spread out the run times. You could for instance have another service running an integration load during the day, and a separate service on the same server running discoveries at night.

  4. MID Servers in Containers - The Future

    I would be amiss if I didn’t talk about the very obvious future of MID Servers in the ecosystem. More and more applications are moving towards containerized approaches, such as with a Docker image, and I would imagine MID server would move that way as well. A docker image can be set up with a specific operating system and configuration, and can be spun up and down with a click of a button. It would be a more cost effective approach to just use what you need, and it would be easier to quickly scale up and down devices. I hope ServiceNow invests in this technology in the future.

I hope MID Server administration practices become much more mainstream as time progresses!