ePortal storage optimization improvement

The TuxCare Team is always looking for new ways to improve the experience provided by our products. A pain point we identified was the amount of storage space required to hold KernelCare patchsets and the network bandwidth required to transfer that information to ePortal deployments.

One of the improvements currently being developed is the ability to configure ePortal to function in a new cache mode, where full functionality is retained while reducing storage requirements by up to 80% in some scenarios.

Currently, ePortal will download and store patchsets to have them available for client systems, and the storage requirements are created around that paradigm – 100GB minimum, with 200GB recommended storage being available for an ePortal deployment.

Image 1 – ePortal high level overview

With cache mode, the storage can be reduced to around 20GB and still provide the same functionality for client systems. 

This is achieved by a combination of smarter data transfer, with only metadata being transferred initially instead of complete patchsets when available, and a two-week retention period for actually used patchsets, as opposed to previous behavior.

Image 2 – ePortal with Cache Mode high level overview. Note that Patches DB no longer stores the whole patchsets in the filesystem unless a protected host actually requests them.

Conceptually, this is similar to how a web proxy caches often used content, rather than contacting the server each time (not to be confused with the existing ability to define a proxy for ePortal communication).

For example, when a new patchset is available, ePortal will download the metadata related to that patchset. When it is actually needed for a client system, the patchset is downloaded and sent to the client, as usual, and it is also stored in the ePortal system for up to two weeks, to respond to other clients who ask for it. In an Enterprise environment, this is the most common scenario, as there are multiple systems running the same distributions.  

For now, cache mode can be enabled by first stopping ePortal service, then setting 

CACHE_MODE = True

in the ePortal configuration file located at /usr/share/kcare-eportal/config/local.py, followed by

kc.eportal cache-mode --fetch-meta

then starting the ePortal service again. As with any changes, you should start by testing it in a smaller deployment or lab scenario.

And while by itself this functionality already provides benefits to existing ePortal users, the team is already working on new and exciting features that will further extend and improve upon this cache mode.

We are always open to suggestions and ideas that can improve your workflow and product usage. If you find that your current ePortal/KernelCare processes could be improved or automated in some way that is not yet covered, reach out to us, we would be delighted to discuss your suggestions with you.

Find out more about KernelCare Enterprise, ePortal, and other TuxCare services, and discover how we can simplify your IT operations with reliable Live Patching solutions on the TuxCare website here.