RT mit Redis nutzen

Vor ein paar Tagen bin ich auf einen Artikel im Netways Blog gestoßen, da ging es um die Speicherung der RT User Sessions in der NoSQL DB Redis.

Da ich seit langem einen brauchbaren Weg suche, unsere nicht wenigen User Verbindungen im RT sinnvoll zu speichern, (nein, das geht in MySQL etc. nur verdammt schlecht!) weckte der Artikel gleich meine Neugier.

Fangen wir aber mal weiter vorne an, also am Anfang, bei Adam und Eva. Mein lieber Kollege Nils hat vor 18 Jahren den RT bei uns installiert und sich dann nach Canada verdrückt, so habe ich das Teil an die Backe bekommen.

Damals installiert auf einem kleinen PC, 1 Queue, 5 User. Da klappt alles ohne Probleme. Mit der Zeit wurden sowohl die Queues aber vor allem die User immer mehr und wir musste was ändern….

Erst haben wir den Webserver von der Datenbank getrennt, dann reichte ein Webserver nicht mehr und wir brauchten mehrere, das klappte auch anfänglich recht gut. Allerdings bekamen wir, je mehr User wir hatten, immer mehr Probleme mit DB Locks der MySQL Datenbank. (Bestpractical nutzt für die Speicherung der User Sessions das Modul Apache::Session und spricht mit dem Perl Modul Apache::Session::MySQL mit der DB. Leider macht dieses Modul einen Table Lock, was bei der Menge an Verbindungen zur Session Table nicht gut ist.)

Dann stellen wir das irgendwann um auf Apache::Session::MySQL::NoLock um die nervigen DB Locks los zu werden. Auch das ging eine Zeit lang gut, bis die Anzahl der RT Nutzer immer weiter stieg. Irgendwann machten die Session Verbindungen den meisten Traffik in unserer MySQL DB aus, weshalb wir das auf Apache::Session::File umstellten und die Sessions im Filesystem ablegten.

Leider mussten wir auch das aus dem physikalischen Filesystem recht schnell entfernen und auf eine Speicherung im einer RAM Disk umstellen, quasi eine Art Redis, nur im Filesystem 😉

Der Nachteil dieser Lösung ist aber, dass damit die User Sessions fest auf einem Webserver liegen. Da wir 4 große Webserver hinter einem Loadbalancer betreiben, waren die User immer wieder genervt, wenn der LBL die User Verbindungen geschwenkt hat und diese sich neu anmelden mussten, was ich gut verstehen kann.

Nun kommt die besprochene Lösung von Netways ins Spiel. Es gibt da diese NoSQL Datenbank Redis, die quasi auch im RAM läuft und das passende Perl Module Apache::Session::Redis gleich dazu.

Damit können wir nun unsere User Sessions, außerhalb der MySQL DB und nicht in einem Filesystem auf einem Webserver speichern. Da es im RAM des Redis Servers läuft, sind die Zugriffe sogar schneller als auf die RAM Disk des Webservers (dort liegen die in einem Verzeichnis und immer 2 Dateien pro User. Bei 10-15.000 User pro Server, kommt da einiges an Files zusammen, macht da mal ein simples LS!)

Da wir im nächsten Schritt, die Webserver abschaffen und in Docker Container verlegen werden, wäre die Speicherung der User Sessions im Filesystem ohne hin nicht mehr möglich gewesen.

Kommen wir aber wieder zurück zum Ursprung dieses Artikels und zwar dem Blogpost von Netways. Ich habe den am Montag mit Spannung gelesen und gleich ausprobieren wollte. Also rauf auf meine Testumgebung, Redis Server aufgesetzt, die empfohlenen Einträge in der RT_SiteConfig.pm vorgenommen und siehe da: Nix, RT TOT! Prima, da fehlt was.

Ich ruf also in Nürnberg an, werde sofort von einer netten Dame an den entsprechenden Techniker geleitet, Problem geschildert….er: Melde mich morgen dazu, wenn das ok ist? Klaro, wir haben Montag Abend!

Nach einigen Gesprächen fingen wir dann an, das was wir testen auch in GIST festzuhalten und um es kurz zu machen, ich bin so ein DEPP, wenn ich Redis verwenden will, sollte ich auch Redis Perl Module installieren und nicht nur das Apache Modul.

1000 Dank auf jeden Fall an Marius und die Firma Netways für die tollen Ideen und den prompten Support. Aber auch an meine tolle Twitter Community rund um @dnsmichi und natürlich @mxhash möchte hier lobend erwähnen! Wenn Ihr das auch probieren wollt oder bei Euch umsetzen, das Team von Netways ist da sicher für jede Schandtat zu haben 😉

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert