A common issue many multi-tenant Elasticsearch deployments face is having a “noisy neighbor” – a certain customer interfering with the service and user experience of another customer on the same cluster.
In cases like these, it’s imperative to locate the noisy neighbor and set up a mechanism to limit or block their usage or transfer them to a different, separate cluster. At other times, clusters may simply become too large with too many customers sharing the same resources, at which point it’s best to split the users to different clusters according to SLA (service level agreement).
Unfortunately, it can be difficult to locate noisy neighbors in Elasticsearch.
A single tenant can affect the search results of others, whether due to indexing bursts, many index exceptions, a single slow search or other factors.
Even though the loading activity is happening on dedicated specific indices for that tenant, all other tenants on the same cluster will exhibit decreased performance, and identifying which tenant is the original “culprit” causing the load is easier said than done. The only way to do so is to spread out as many metrics as possible to track and detect which tenant was the first to be “noisy”.
After correctly identifying the noisy neighbor, you need to take the appropriate actions to ensure it doesn’t interfere with the performance of the other tenants.
Opster’s Multi-Cluster Load Balancer locates noisy neighbors by providing all of the operation stats for each tenant and identifying heavy searches and increased indexing or search activity automatically.
Once noisy neighbors are easily detected, the Load Balancer affords users multiple ways to mitigate the issue – from changing the index settings and mappings, moving the user to a separate cluster or blocking the user’s heavy searches.