A common issue many multi-tenant OpenSearch 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 OpenSearch.
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.
Watch the video below to learn how to detect and resolve noise tenant issues in your deployment.
We are sorry that this post was not useful for you!
Let us improve this post!
Tell us how we can improve this post?