Redis Performance Replikation Setup

Redis Replikation/Performace:
Die Redis Datenbank ist eine Store-Value Datenbank, wie beispielsweise die bekannte Memcached Datenbank. Store-Value Datenbanken verfügen über eine relativ einfache Logik, daher beherrschen diese nur einfache Abfragen.

Magento Redis DB

Das ist ein kleines Beispiel wie die Redis DB funktioniert:

SET kunde_1 1234
-> OK
GET kunde_1
-> 1234

Der SET Befehl speichert "1234" zur Variable "kunde_1". Wenn man die Variable mit "GET" abruft, bekommt man in der Ausgabe der Redis DB den Wert "1234".
Diese einfache Abfrage ist besonders geeignet, wenn es um einfache Speicherwerte geht, die nicht in der Abfrage verglichen werden sollen.

Als Beispiel wäre die PHP Session genannt, zum Speichern von Warenkörben in Magento oder Userdaten in Drupal.
Magento und Drupal arbeitet mit Zwischenspeicherungen, auch Cache genannt und können diesen Cache in eine Datenbank speichern.

Hier eine Auflistung von Pro und Contra beim Einsatz von Redis bei einem Drupal oder Magento Projekt:

Die Vorteile von Redis:

  • Zentralisiertes Caching
  • Durch Replikation schneller Schreibzugriff von Node zu Daten, wenn Datenbank redundant ausgelegt ist
  • Extrem performante Replikation
  • Master/Slave Setup mit Read-Only Slave möglich
  • Schnelle und sichere Implementierung in PHP-Applikation z.B. Magento oder Drupal, da Extensions verfügbar
  • Schreibbefehle müssen nur auf einem Node ausgeführt werden, im Gegensatz zum Beispiel zu Memcached


Die Nachteile:

  • Caching funktioniert nicht über direkten Memory Zugriff, sondern über Unix-Socket oder TCP/IP Socket
  • Zusätzliche Verwaltung der Dienste nötig
  • Redis DB kann nur über einen Prozessor Thread laufen
  • Lokaler Cache wie APC ist schneller

Der Einsatz:
Redis wird vor allem bei größeren, stark frequentierten Projekten eingesetzt, welche über mehrere Webserver verteilt arbeiten müssen und zentralisiertes Caching benötigen. Der Vorteil im zentralen Cache liegt darin, dass PHP immer auf die selbe Session und den selben Cache zugreifen kann. Man kann also auf N PHP/Webserver(zum Beispiel Apache) Nodes die Performance verteilen und auf einen zentralen Cache und eine zentrale Session zurückgreifen.


Ein Beispiel Setup:

Das Setup zeigt einen weiteren PHP Node, welcher verwendet werden kann im Master/Slave Gespann.
Die Nodes greifen immer auf den Master zu, möchte mann einen weiteren Slave nutzen, müsste man dann aber in der PHP Applikation, also Magento oder Drupal die Master/Slave Logik abbilden.

Redis Master Slave Magento

Auch bei größeren Projekten ist meist die Performance mit nur einer Master Redis DB gut. Bei einem Ausfall des Master Hosts, wird der vorher definierte Slave zum Master und erhält dessen IP Adresse und Aufgabe. Die Replikation übernimmt Redis, jedoch übernimmt Corosync/Pacemaker die Hochverfügbarkeit und das Zuweisen von Master und Slave.
Somit ist ein nahtloser Betrieb möglich, da der Slave im Slave-Modus Read-Only ist und im Master-Mode die Daten des Master hat.

Adressen und Namen für das Setup:

Node1 - 192.168.1.200
Node2 - 192.168.1.201
HA Master IP
192.168.1.202


Cluster Agents:

Für die Hochverfügbarkeit der Redis DB, wurde in Zusammenarbeit mit der Afdata Systems GmbH die Resource Agents vollständig neu implementiert und auf Github https://github.com/afdata/resource-agents veröffentlicht.

FASTNODE:
Natürlich bieten wir ganz individuelle Lösungen für solch ein Setup an. Kontaktieren Sie uns einfach: http://www.fastnode.de/

Weitere Quellen:
http://redis.io
http://www.linux-ha.org/wiki/Resource_Agents
https://github.com/afdata/resource-agents/wiki

Folge Patrick Emer auf Google+