PHP an Valkey Sentinel anbinden und beweisen, dass das Failover funktioniert

Viele Websites betreiben einen replizierten Redis- oder Valkey-Cache und fallen trotzdem aus, wenn der Primary stirbt, weil die Anwendung auf eine feste Adresse zeigt. Die Replicas sind da, Sentinel befördert eines, und PHP klopft weiter an die Tür des toten Servers. So bauen Sie den Cache, damit das Failover die Anwendung tatsächlich erreicht, und so beweisen Sie es, bevor Sie es brauchen.

Warum der Cache Teil Ihrer Verfügbarkeit ist

Ein Object Cache speichert berechnete Ergebnisse: Optionen, Menüs, Sessions, Abfrageergebnisse, gerenderte Fragmente. Auf einer stark besuchten WordPress-, Magento- oder Laravel-Site nimmt er den Großteil der Leselast der Datenbank auf. Verlieren Sie ihn, geht jede Anfrage auf einmal zurück an die Datenbank. Die Datenbank wurde nie dafür dimensioniert, also kriecht die Site innerhalb von Minuten. Eine einzelne Cache-Instanz ist deshalb ein Single Point of Failure, obwohl sie nichts hält, was Sie nicht neu aufbauen könnten.

Die Form: ein Primary, zwei Replicas, drei Sentinels

Betreiben Sie drei Cache-Knoten auf drei getrennten Hosts: einen Primary und zwei Replicas. Neben jedem läuft ein Sentinel-Prozess. Die Sentinels beobachten den Primary, einigen sich untereinander, wann er weg ist, befördern ein Replica und beantworten die Frage, auf die jeder Client eine Antwort braucht: Wo ist der Primary jetzt?

Auf jedem Replica:

replicaof <primary-address> 6379
masterauth <secret>
requirepass <secret>

Und auf jedem der drei Sentinels:

sentinel monitor cache <primary-address> 6379 2
sentinel auth-pass cache <secret>
sentinel down-after-milliseconds cache 5000
sentinel failover-timeout cache 30000
sentinel parallel-syncs cache 1

Die 2 in der monitor-Zeile ist das Quorum: Zwei von drei Sentinels müssen sich einig sein, dass der Primary down ist, bevor ein Failover beginnt. Deshalb sind es drei, auf drei verschiedenen Hosts.

down-after-milliseconds ist die Abwägung zwischen Geschwindigkeit und Vorsicht. Wir halten es kurz. Ein unnötiges Failover kostet ein paar Sekunden Cache Misses. Ein langes Warten mit totem Primary kostet eine kriechende Datenbank.

Der Schritt, den alle auslassen: Clients, die Sentinel fragen

Ein Client, der mit der Adresse des Primary konfiguriert ist, erfährt nie von einer Promotion. Die Anwendung muss sich über Sentinel verbinden, per Dienstname, und nach dem aktuellen Primary fragen.

Mit phpredis direkt:

$sentinel = new RedisSentinel(['host' => '<sentinel-1>', 'port' => 26379]);
[$host, $port] = $sentinel->getMasterAddrByName('cache');
$redis = new Redis();
$redis->connect($host, (int) $port);
$redis->auth('<secret>');

Produktionscode sollte jeden Sentinel der Reihe nach versuchen, da jeder einzelne auf dem Host liegen kann, der gerade ausgefallen ist.

Für WordPress unterstützt das weit verbreitete Drop-in Redis Object Cache Sentinel nativ in der wp-config.php:

define('WP_REDIS_CLIENT', 'phpredis');
define('WP_REDIS_SENTINEL', 'cache');
define('WP_REDIS_SERVERS', [
    'tcp://<sentinel-1>:26379',
    'tcp://<sentinel-2>:26379',
    'tcp://<sentinel-3>:26379',
]);
define('WP_REDIS_PASSWORD', '<secret>');

Laravel nimmt über Predis eine Liste von Sentinels und zwei Optionen in config/database.php entgegen:

'redis' => [
    'client' => 'predis',
    'default' => [
        'tcp://<sentinel-1>:26379',
        'tcp://<sentinel-2>:26379',
        'tcp://<sentinel-3>:26379',
        'options' => ['replication' => 'sentinel', 'service' => 'cache'],
    ],
],

Damit braucht eine Promotion keine Konfigurationsänderung und keinen Neustart von PHP.

Speicher: begrenzen und festlegen, wer verdrängt wird

Ein Cache, der wächst, bis der OOM-Killer des Kernels eingreift, ist auf die schlimmstmögliche Weise gescheitert. Setzen Sie maxmemory auf einen festen Anteil des RAM des Knotens, mit Platz für die Replikationspuffer und den Fork für die Persistenz, und wählen Sie die Eviction Policy bewusst:

• allkeys-lru für einen reinen Cache. Wenn der Speicher voll ist, fliegt der am längsten nicht genutzte Key, was immer er ist. Das ist richtig für Object Caches.
• volatile-lru, wenn die Instanz auch Keys ohne Ablauf hält, die nie verdrängt werden dürfen, etwa Sessions. Nur Keys mit TTL sind Kandidaten.

Noch besser: Halten Sie Sessions und Object Cache getrennt. Ein Deploy, das den Object Cache leert, sollte nie jeden Kunden ausloggen. Auf einem geteilten Cluster geben Sie jeder Site mindestens ihre eigene logische Datenbank. Geben Sie großen oder kritischen Sites eine eigene Instanz, damit das Leeren oder ein unkontrolliertes Key-Wachstum einer Site nicht die Caches ihrer Nachbarn leeren kann.

Beweisen Sie es: Töten Sie den Primary absichtlich

Ein Failover, dem Sie nicht zugesehen haben, ist eine Hoffnung. Vor der Übergabe führen wir dies mit verbundener Anwendung und laufendem Traffic aus:

# 1. Who is primary right now?
valkey-cli -p 26379 SENTINEL get-master-addr-by-name cache

# 2. Watch the site from outside, timestamped
while true; do
  printf '%s ' "$(date +%T.%N)"
  curl -s -o /dev/null -w '%{http_code} %{time_total}\n' https://www.example.com/
  sleep 0.5
done | tee cache-failover.log

# 3. On the primary's host, stop the cache service
systemctl stop valkey

# 4. Watch the Sentinel log for +switch-master, then ask again
valkey-cli -p 26379 SENTINEL get-master-addr-by-name cache

(Mit Redis sind die Befehle dieselben unter redis-cli.)

Notieren Sie drei Dinge: wie lange es dauert, bis +switch-master erscheint, wie lange, bis die Seitenzeiten wieder normal sind, und ob irgendeine Anfrage fehlgeschlagen ist, statt nur langsamer zu werden. Ein gesunder Aufbau befördert in wenigen Sekunden, und PHP folgt, ohne dass jemand eingreift. Starten Sie dann den alten Primary wieder und bestätigen Sie, dass er als Replica des neuen zurückkehrt, nicht als zweiter Primary.

Für eine sanftere Probe, die keinen Dienst stoppt, erzwingt SENTINEL FAILOVER cache eine Promotion auf Abruf. Nützlich, um die Client-Seite zu testen. Weniger nützlich, um die Erkennung zu testen, und die ist der Teil, der in einer schlechten Nacht zählt.

Ihre Checkliste

• Drei Cache-Knoten und drei Sentinels auf drei getrennten Hosts, Quorum zwei.
• Authentifizierung aktiv, und der Cache nur aus dem Web-Tier erreichbar, das ihn nutzt.
• Jede Anwendung verbindet sich über Sentinel per Dienstname, nicht mit einer festen Adresse.
• maxmemory gesetzt und eine Eviction Policy gewählt, die zu dem passt, was die Instanz hält.
• Sessions vom Object Cache getrennt. Große Sites von kleinen isoliert.
• Ein protokollierter Failover-Test mit verbundener Anwendung, einschließlich der Rückkehr des alten Primary.

Wenn wir Ihre Cache-Schicht verdrahten oder testen sollen, tun wir das gern.

Mit einem Ingenieur sprechen

Related (rows[1])

Verwandte Themen: Object Caching mit automatischem Failover · Hochverfügbare Web-Tiers, N+1 auf jeder Ebene · Hochverfügbare Plattform-Builds