Gluster blog stories provide high-level spotlights on our users all over the world
One of the salient features in Gluster 3.10 goes by the rather boring – and slightly opaque – name of brick multiplexing. To understand what it is, and why it’s a good thing, read on.
First, let’s review some relevant parts of how Gluster works already. All storage in Gluster is managed as bricks, which are just directories on servers. Often they’re whole disks or volumes on servers, but that doesn’t have to be the case. It has always been possible to have multiple bricks per server, or even per disk, though carving things up into two many pieces could have some unpleasant effects involving various kinds of resources.
Brick multiplexing is just a term for putting multiple bricks into one process. Therefore, many bricks can consume *one* port, *one* set of global data structures, and *one* pool of global threads. This reduces resource consumption, allowing us to run more bricks than before – up to three times as many in some tests involving the very large numbers of bricks that might be involved in a container/hyperconverged kind of configuration.
In addition to reducing overall contention for these resources, brick multiplexing also brings that contention under more direct control. Previously, we were at the mercy of the operating system’s scheduler and paging system to manage this contention. They’d have to make many guesses about what we need, and often they’d guess wrong. We *know*. Now that multiple bricks can run in one process, we can manage contention more carefully to match our priorities and policies. Some day, this will even be the lever we can use to provide multi-tenant isolation and quality of service.
It’s important to note that multiplexing is *not* primarily a performance enhancer. At low brick counts – e.g. less than the number of CPU cores on a system – you’re probably better off not multiplexing. This is true both because of performance and to keep failure domains smaller. In the mid range (hundreds of bricks) multiplexing might or might not perform process-per-brick, depending on workload. Mostly this is not because of multiplexing itself but because of other changes – such as a much more scalable memory-pool implementation – that were developed along with it. There’s still some untapped potential here, so over time multiplexing is likely to improve performance in more cases. At the high end (thousands of bricks) multiplexing is the only option; that many separate brick processes eventually consume so many resources and thrash so much that no useful work gets done.
In short, multiplexing is already helping us address the particular needs of container and hyperconverged workloads. It also provides the infrastructure on which other enhancements can be built which will provider greater benefits to even more users.
Congratulations to the team for getting Gluster 6 released! https://www.gluster.org/announcing-gluster-6/ https://lists.gluster.org/pipermail/gluster-users/2019-March/036144.html Our retrospective survey is open through April 8th, give us feedback on what we should start, stop or continue! https://lists.gluster.org/pipermail/gluster-users/2019-March/036144.html Gluster 7 Roadmap Discussion kicked off for our 7 roadmap on the mailing lists, see [Gluster-users] GlusterFS...
The Gluster community is pleased to announce the release of 6.0, our latest release. This is a major release that includes a range of code improvements and stability fixes along with a few features as noted below. Specifically, this release addresses one of the major concerns regarding FUSE mount process memory...