From 382fcca5301ae2f00fa8b63f10c503bd6cffed98 Mon Sep 17 00:00:00 2001 From: Daniel dos Santos Pereira Date: Mon, 10 May 2021 10:43:30 -0300 Subject: [PATCH] Docs: delete from high availability docs references to removed configurations related to session storage (#33827) * docs: delete from high availability docs references to removed configurations related to session storage * docs: remove session storage mention and focus on the auth token implementation --- .../set-up-for-high-availability.md | 20 +------------------ 1 file changed, 1 insertion(+), 19 deletions(-) diff --git a/docs/sources/administration/set-up-for-high-availability.md b/docs/sources/administration/set-up-for-high-availability.md index 3cbcb682e7e..e49cfed4d2e 100644 --- a/docs/sources/administration/set-up-for-high-availability.md +++ b/docs/sources/administration/set-up-for-high-availability.md @@ -26,22 +26,4 @@ Currently alerting supports a limited form of high availability. [Alert notifica ## User sessions -> **Note:** You don't need to configure session storage, because the database will be used by default. -> If you want to offload the login session data from the database, then you can configure [remote_cache]({{< relref "../administration/configuration.md" >}}#remote-cache). - -The second thing to consider is how to deal with user sessions and how to configure your load balancer in front of Grafana. -Grafana supports two ways of storing session data: locally on disk or in a database/cache-server. -If you want to store sessions on disk you can use `sticky sessions` in your load balancer. If you prefer to store session data in a database/cache-server -you can use any stateless routing strategy in your load balancer (ex round robin or least connections). - -### Sticky sessions - -Using sticky sessions, all traffic for one user will always be sent to the same server. Which means that session related data can be -stored on disk rather than on a shared database. This is the default behavior for Grafana and if you only want multiple servers for fail over this is a good solution since it requires the least amount of work. - -### Stateless sessions - -You can also choose to store session data in a Redis/Memcache/Postgres/MySQL which means that the load balancer can send a user to any Grafana server without having to log in on each server. This requires a little bit more work from the operator but enables you to remove/add grafana servers without impacting the user experience. -If you use MySQL/Postgres for session storage, you first need a table to store the session data in. More details about that in [[sessions]]({{< relref "../administration/configuration.md" >}}#session) - -For Grafana itself it doesn't really matter if you store the session data on disk or database/redis/memcache. But we recommend using a database/redis/memcache since it makes it easier to manage the grafana servers. +Grafana uses auth token strategy with database by default. This means that a load balancer can send a user to any Grafana server without having to log in on each server. If you want to offload the login session data from the database, then you can configure [remote_cache]({{< relref "../administration/configuration.md" >}}#remote-cache).