IntenseWebs/grafana
3
0
Fork 0
mirror of https://github.com/grafana/grafana.git synced 2025-02-25 18:55:37 -06:00
Code Issues Packages Projects Releases Wiki Activity

Docs: delete from high availability docs references to removed configurations related to session storage (#33827)

Browse Source 
* 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
This commit is contained in:
Daniel dos Santos Pereira 2021-05-10 10:43:30 -03:00 committed by GitHub
parent 4c83ab5610
commit 382fcca530
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
docs/sources/administration/set-up-for-high-availability.md
View File

@ -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).