Σύνδεση της PHP με Valkey Sentinel, και απόδειξη ότι το failover δουλεύει

Πολλά sites τρέχουν ένα replicated cache Redis ή Valkey και πέφτουν παρ' όλα αυτά όταν πεθάνει το primary, γιατί η εφαρμογή δείχνει σε μία σταθερή διεύθυνση. Τα replicas είναι εκεί, το Sentinel προάγει ένα, και η PHP συνεχίζει να χτυπά την πόρτα του νεκρού server. Να πώς χτίζετε το cache ώστε το failover να φτάνει πραγματικά στην εφαρμογή, και πώς το αποδεικνύετε πριν το χρειαστείτε.

Γιατί το cache είναι μέρος της διαθεσιμότητάς σας

Ένα object cache αποθηκεύει υπολογισμένα αποτελέσματα: options, μενού, συνεδρίες, αποτελέσματα queries, αποδοσμένα τμήματα. Σε ένα πολυάσχολο site WordPress, Magento ή Laravel απορροφά το μεγαλύτερο μέρος του φόρτου reads της βάσης δεδομένων. Χάστε το, και κάθε αίτημα γυρίζει στη βάση ταυτόχρονα. Η βάση δεν διαστασιολογήθηκε ποτέ για αυτό, οπότε το site σέρνεται μέσα σε λίγα λεπτά. Ένα μοναδικό instance cache είναι επομένως μοναδικό σημείο αποτυχίας, παρόλο που δεν κρατά τίποτα που δεν μπορείτε να ξαναχτίσετε.

Το σχήμα: ένα primary, δύο replicas, τρία Sentinels

Τρέξτε τρεις κόμβους cache σε τρεις ξεχωριστούς hosts: ένα primary και δύο replicas. Δίπλα στον καθένα, τρέξτε μια διεργασία Sentinel. Τα Sentinels παρακολουθούν το primary, συμφωνούν μεταξύ τους πότε έχει χαθεί, προάγουν ένα replica, και απαντούν στην ερώτηση που κάθε client χρειάζεται απαντημένη: πού είναι το primary τώρα;

Σε κάθε replica:

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

Και σε καθένα από τα τρία 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

Το 2 στη γραμμή monitor είναι το quorum: δύο από τα τρία Sentinels πρέπει να συμφωνήσουν ότι το primary είναι down πριν ξεκινήσει failover. Γι' αυτό είναι τρία, σε τρεις διαφορετικούς hosts.

Το down-after-milliseconds είναι το trade-off ανάμεσα σε ταχύτητα και επιφύλαξη. Εμείς το κρατάμε μικρό. Ένα περιττό failover κοστίζει λίγα δευτερόλεπτα cache misses. Μια μεγάλη αναμονή με νεκρό primary κοστίζει μια βάση που σέρνεται.

Το βήμα που παραλείπουν: clients που ρωτούν το Sentinel

Ένας client διαμορφωμένος με τη διεύθυνση του primary δεν θα μάθει ποτέ για ένα promotion. Η εφαρμογή πρέπει να συνδέεται μέσω Sentinel, με όνομα υπηρεσίας, και να ζητά το τρέχον primary.

Με phpredis απευθείας:

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

Ο κώδικας παραγωγής πρέπει να δοκιμάζει κάθε Sentinel με τη σειρά, αφού οποιοδήποτε από αυτά μπορεί να βρίσκεται στον host που μόλις απέτυχε.

Για WordPress, το ευρέως χρησιμοποιούμενο drop-in Redis Object Cache υποστηρίζει Sentinel εγγενώς στο 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, μέσω Predis, παίρνει μια λίστα Sentinels και δύο επιλογές στο config/database.php:

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

Με αυτά στη θέση τους, ένα promotion δεν χρειάζεται καμία αλλαγή διαμόρφωσης και καμία επανεκκίνηση της PHP.

Μνήμη: βάλτε όριο και επιλέξτε ποιος φεύγει

Ένα cache που μεγαλώνει μέχρι να παρέμβει ο OOM killer του kernel έχει αποτύχει με τον χειρότερο δυνατό τρόπο. Ορίστε το maxmemory σε σταθερό μερίδιο της RAM του κόμβου, αφήνοντας χώρο για τα replication buffers και το fork που χρησιμοποιείται για persistence, και επιλέξτε eviction policy συνειδητά:

• allkeys-lru για καθαρό cache. Όταν η μνήμη γεμίσει, φεύγει το λιγότερο πρόσφατα χρησιμοποιημένο key, όποιο κι αν είναι. Αυτό είναι το σωστό για object caches.
• volatile-lru αν το instance κρατά και keys χωρίς λήξη που δεν πρέπει ποτέ να φύγουν, όπως συνεδρίες. Μόνο keys με TTL είναι υποψήφια.

Ακόμη καλύτερα, κρατήστε συνεδρίες και object cache χωριστά. Ένα deploy που αδειάζει το object cache δεν πρέπει ποτέ να αποσυνδέει κάθε πελάτη. Σε κοινόχρηστο cluster, δώστε σε κάθε site τη δική του λογική βάση κατ' ελάχιστο. Δώστε στα μεγάλα ή κρίσιμα sites δικό τους instance, ώστε το άδειασμα ή η ανεξέλεγκτη αύξηση keys ενός site να μην μπορεί να αδειάσει τα caches των γειτόνων του.

Αποδείξτε το: σκοτώστε το primary επίτηδες

Ένα failover που δεν έχετε παρακολουθήσει είναι ελπίδα. Πριν από την παράδοση, τρέχουμε αυτό με την εφαρμογή συνδεδεμένη και κίνηση να ρέει:

# 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

(Με Redis, οι εντολές είναι οι ίδιες με redis-cli.)

Σημειώστε τρία πράγματα: πόσος χρόνος μέχρι να εμφανιστεί το +switch-master, πόσος χρόνος μέχρι οι χρόνοι των σελίδων να επιστρέψουν στο κανονικό, και αν κάποιο αίτημα απέτυχε αντί απλώς να καθυστερήσει. Μια υγιής κατασκευή προάγει σε λίγα δευτερόλεπτα, και η PHP ακολουθεί χωρίς να την αγγίξει κανείς. Μετά ξεκινήστε ξανά το παλιό primary και επιβεβαιώστε ότι επανεντάσσεται ως replica του νέου, όχι ως δεύτερο primary.

Για μια πιο ήπια πρόβα που δεν σταματά υπηρεσία, το SENTINEL FAILOVER cache επιβάλλει promotion κατ' απαίτηση. Χρήσιμο για δοκιμή της πλευράς του client. Λιγότερο χρήσιμο για δοκιμή της ανίχνευσης, που είναι το κομμάτι που μετράει μια κακή νύχτα.

Η λίστα ελέγχου σας

• Τρεις κόμβοι cache και τρία Sentinels σε τρεις ξεχωριστούς hosts, quorum δύο.
• Αυθεντικοποίηση ενεργή, και το cache προσβάσιμο μόνο από το web tier που το χρησιμοποιεί.
• Κάθε εφαρμογή να συνδέεται μέσω Sentinel με όνομα υπηρεσίας, όχι σε σταθερή διεύθυνση.
• maxmemory ορισμένο και eviction policy επιλεγμένη για ό,τι κρατά το instance.
• Συνεδρίες χωριστά από το object cache. Μεγάλα sites απομονωμένα από μικρά.
• Μια καταγεγραμμένη δοκιμή failover με την εφαρμογή συνδεδεμένη, μαζί με την επανένταξη του παλιού primary.

Αν θέλετε να στήσουμε ή να δοκιμάσουμε το επίπεδο cache σας, ευχαρίστως.

Μιλήστε με έναν μηχανικό

Related (rows[1])

Σχετικά: Object caching με αυτόματο failover · Web tiers υψηλής διαθεσιμότητας, N+1 σε κάθε επίπεδο · Κατασκευές πλατφορμών υψηλής διαθεσιμότητας