Server Sizing for DCIM and OSP Deployments

Unless a customer purchases a cloud subscription of netTerrain (in which case we provide the server), we usually get a request for help with server sizing during the deployment phase of a DCIM or OSP implementation. This is expected, as the gatekeepers of the IT world have to install the software and they need to know how big of a server they need.

Deployment types

One of the first questions that pops up is: what type of server is needed? Physical or virtual? Is it possible to deploy one on the Cloud that the customer pays?

The answer is: whatever the customer prefers (similar to the payment methods we accept, we adapt to whatever is most convenient for your organization). If you want to search for a cloud platform for you, we can deploy netTerrain on any infrastructure, probably with a slight bias towards Azure or AWS.

netTerrain is a modern n-tiered web-based enterprise-grade software for network, fiber and data center documentation that can be deployed in a variety of configurations. The data tier (database server) and the application tier (application server) can be deployed on the same or on separate (physical or virtual) machines. We typically see that customers prefer virtual environments (the sizing recommendations don’t vary much for either case).

Hardware sizing

Once the deployment type has been identified we have to determine how much ‘juice’ and space we need on the machine (physical or virtual). Space is usually not that much of a factor, but juice is: hard drive type, memory and CPU.

For starters, we always recommend that the customer separate the database and application servers. Next, we proceed to estimate the specs on each. Because this calculation is more of an art than a science, we’ll typically ask the customer a few key questions:

●     Will the server/s be shared with other applications?
●     How many total named users will use the software and how often?
●     How many objects do you plan to manage in the next year or two?
●     How will the users be using the product?

Sharing the server could have a huge impact on the performance (especially when we don’t know which usage peaks we may get from other users accessing a different application unrelated to netTerrain). It’s not the same to install netTerrain on a machine dedicated to that software as it is to share it with 10 other applications.

The number of named users and the frequency we expect them to access the tool can give us an idea of how many concurrent users we can expect during peak times. We may even ask about the geographical distribution of users to understand how much time zones may or may not overlap. In the absence of real data we usually take the concurrent usage as 10% of the total named users. This is probably a conservative estimate since on average, half the users only access the tool on a weekly or monthly basis.

Next, we try to determine how many objects will be documented in the next year or two. This approach is better than simply taking the maximum object count from the license. For starters some licenses are unlimited. Also, while we always try to get the customer to buy the licenses they will be needing just for the short term, sometimes customers do start big, but that does not mean they will get near that count limit during the first two years of usage.

Finally, we look into the way the system is going to be used.

For instance: if the system is used for Data Center Infrastructure Management we can expect a large presence of racks and rack mounted devices. These objects are more processing-intensive than, say, a logical object utilized in a network topology map used for IT documentation in netTerrain Logical. If the customer is using netTerrain for fiber plant and outside plant diagrams, then we may expect bursts of processing when loading a densely populated map.

With all this knowledge, we try to fit these variables into one of three categories of our hardware specifications so that we keep it simple:

Even with all the information we gather, these specifications may not yield a fast-performing system if there is a higher than expected volume of activity associated with other applications or database systems running in parallel, abnormal spikes in user activity, or other external factors that can slow down disk, CPU, or memory usage. Translation: we can keep adding more fancy scientific looking parameters to give you this warm fuzzy feeling that you’ll have the exact server you need, but we know better. Server sizing and estimation is more an art than a science.

In sum: we always take the table above with a grain of salt.

What are these minimum, standard and optimal sizes based off of, anyways?
The smartypants answer would be that the minimum size is for a small project, the standard one for a medium, and the optimal one for a large one. How clever.

Then, what are the expected object counts and user counts that we can expect to fit a server into one of those three categories? This is, again, a bit fuzzy, but we tend to follow these guidelines:

*A small to medium-sized deployment is one that may have up to 10 concurrent Users and 500 devices. You can use the minimum size for that. Yes, 8GB of RAM is still OK and SQL Express works just fine. You could run netTerrain on an older laptop clunker, which is great!

*A medium to large-sized deployment may have up to 25 concurrent Users and 2500 devices.

*A large to very large project may have up to 100 concurrent users and 25,000 devices.

Concurrent users are counted as users entering or updating the system through the browser at the same time. What about a huge project larger than 25,000 devices? You can still support them with even larger servers or we can set up a special environment where we partition the servers and databases into several chunks.

Happy documenting!