Hardware Guidelines for the KeyServer Host

We are often asked by new K2 administrators for our recommendations on the system that will host their KeyServer. While there is no optimal system configuration — each KeyServer has different usage patterns and load profiles depending on the number of clients it supports and what products are being tracked — we can give some general guidelines to follow when provisioning a computer (real or virtual) that will satisfy most typical installations.

Hardware Guidelines

It is important to note that, while you can run other services and processes on the same computer as KeyServer, there are no requirements to do so. For instance, you do not need to install or configure IIS, SQL Server, or any other service. All that is needed is the OS.

If you follow these guidelines your host computer will have plenty of power to support KeyServer. These are not “minimum requirements”, so it is possible to reduce the resources and still run KeyServer without severe performance degradation. It is also possible (and common) for KeyServer to be co-hosted with other network services.

Computing Resources

Broadly speaking, there are four classes of computing resources that any program uses:

• Mass storage (Disk)
• Dynamic storage (RAM)
• Processing power (CPU)
• Network Throughput

We’ll comment on these individually below, to help you make a more informed decision on how you allocate resources to the server computer.

Mass Storage (Disk)

KeyServer spends much of its effort storing the data it collects in disk-based databases. Because a large KeyServer can collect massive amounts of data, having a fast disk is paramount. And while SSDs are orders of magnitude faster than traditional disks, the disk I/O still presents a bottleneck. When all of KeyServer’s data is stored on a single disk, KeyServer will serialize its disk I/O (the single disk controller would also serialize the I/O). For large KeyServers, if data files are spread across multiple disks I/O will be multiplexed, improving performance incrementally.

Because a server process like KeyServer is “disk bound”, the disk configuration is one of the most important resources to focus on. Spend your resource chits on a fast disk before spending them on a fast CPU.

Over time, KeyServer can gather a large amount of data for each installed client.  The above disk guidelines should be more than sufficient for a few years of data, and also leave enough free space for data to be duplicated during KeyServer upgrades.  If you also enable the internal Backup feature, additional space will be needed.  Since the disk space usage will grow slowly over time, you will have plenty of time to observe the disk usage for your specific server, and adjust the available disk space as needed.

Dynamic storage (RAM)

In its basic configuration, KeyServer does not require a large amount of memory. However, the OS will use available memory as a general purpose “file system cache” that will effectively speed up disk access. The more RAM installed on a system, the larger this cache will be. While default settings for a KeyServer leave the file system in charge of its memory access, it is possible to increase the sizes of various KeyServer-specific disk caches to reduce disk I/O and increase performance. This is a trade-off with the OS’s file system cache (and other processes running on the system), which also affects overall performance. For a KeyServer supporting up to 20,000 clients the default memory usage is sufficient. For larger installations, Sassafras can provide details on tuning KeyServer’s memory allocation to optimize performance.

After fast disk storage, the next priority is RAM size. More RAM means a larger disk cache, which improves I/O performance on even the fastest disk storage.

Processing power (CPU)

For data-intensive services like KeyServer, the I/O bottlenecks will overshadow CPU overhead. However, as disk I/O throughput is increased by faster disks (such as SSDs or disk multiplexing), the CPU’s performance can play a larger role. Certain functionality like encryption requires more CPU horsepower, but a modern multicore CPU will provide the computing power needed by even a large KeyServer.

Increased CPU power will always help, but focus first on a fast disk and ample RAM. Add CPU cores if you plan to use KeyServer’s Web interface for providing Reporting and Dashboard services to a broad audience.

Network Throughput

Since KeyServer is a network service, adding more clients will increase network traffic linearly (actually, traffic growth will be slightly less than linear since KS will scale parts of the protocol as load increases). At the server, Gigabit (or faster) Ethernet is a requirement only for very large installations. The speed of clients’ network connections is less important.

The KeyServer protocol works most efficiently when all of its traffic is allowed to pass between client and server, and not blocked by firewalls. By design, the protocol is tolerant of typical firewall configurations that will block some KeyServer traffic. But this fault tolerance comes at a small price in performance, which can be reclaimed by configuring firewalls (whether network- or client-based) to allow all KeyServer traffic.

Network Speed (Bandwidth) of modern networks is plenty fast for KeyServer, which was designed to support networks slower than anything in use today. Assuming your network is not clogged by other services, it will also have the available throughput for KeyServer traffic.