Ο χάρτης των failure domains, και η δοκιμή μεταβίβασης που τον αποδεικνύει

Κάθε διάγραμμα πλατφόρμας έχει τρία κουτιά βάσης δεδομένων, δύο load balancers και ένα ζεύγος cache, και το καθένα τους έχει την ετικέτα «υψηλής διαθεσιμότητας». Το αν είναι, εξαρτάται από δύο έγγραφα που οι περισσότερες κατασκευές δεν παράγουν ποτέ: έναν χάρτη του από ποια φυσικά πράγματα εξαρτάται κάθε replica, και ένα φύλλο δοκιμών που καταγράφει τι συνέβη όταν αφαιρέθηκε το καθένα. Να πώς τα γράφουμε και τα δύο.

Το πρόβλημα: τρία replicas μπορεί να είναι μία βλάβη

Ο πλεονασμός μετρά αντίγραφα. Η διαθεσιμότητα εξαρτάται από το αν αυτά τα αντίγραφα μπορούν να αποτύχουν ανεξάρτητα. Τρεις κόμβοι βάσης δεδομένων σε τρεις εικονικές μηχανές που ο scheduler έτυχε να τοποθετήσει σε δύο hosts είναι, για μια βλάβη host, δύο κόμβοι. Τρεις κόμβοι σε τρεις hosts των οποίων οι δίσκοι ζουν όλοι σε μία συστοιχία storage είναι, για μια βλάβη συστοιχίας, κανένας. Τίποτα στην εφαρμογή ή στο dashboard δεν σας το λέει. Πρέπει να το γράψετε.

Βήμα πρώτο: καταγράψτε τα failure domains

Για μια τυπική πλατφόρμα, καταγράψτε τουλάχιστον:

• Host: ο φυσικός server ή το blade.
• Chassis ή enclosure: τα blades μοιράζονται τροφοδοσία, ψύξη και interconnects.
• Συστοιχία storage: και, από κάτω της, τη διαδρομή του storage fabric.
• Δίκτυο: το ζεύγος switches top of rack, τα uplinks, το edge.
• Site: παροχή ρεύματος, ψύξη, το ίδιο το κτίριο.

Μετά αποφασίστε ποια από αυτά πρέπει να επιβιώσει η πλατφόρμα. Το να επιβιώνει την απώλεια οποιουδήποτε ενός host και οποιασδήποτε μίας συστοιχίας είναι λογική βάση. Το να επιβιώνει ένα ολόκληρο site χρειάζεται δεύτερο site και είναι διαφορετικός σχεδιασμός.

Βήμα δεύτερο: σχεδιάστε τον χάρτη

Φτιάξτε έναν πίνακα με μία γραμμή ανά μέλος κάθε πλεονάζουσας βαθμίδας και μία στήλη ανά failure domain:

Βαθμίδα	Μέλος	Host	Chassis	Συστοιχία
database	db-a	host 1	enclosure 1	array A
database	db-b	host 2	enclosure 2	array B
database	db-c	host 3	enclosure 1	array C
cache	cache-a	host 2	enclosure 2	array A
...

Ο κανόνας είναι απλός: μέσα σε μία βαθμίδα, κανένα failure domain που έχετε επιλέξει να επιβιώσετε δεν επιτρέπεται να κρατά την πλειοψηφία των μελών. Διαβάστε κάθε στήλη προς τα κάτω για κάθε βαθμίδα. Δύο από τα τρία μέλη της βάσης δεδομένων στο enclosure 1 σημαίνει ότι μια βλάβη enclosure σπάει το quorum. Διορθώστε την τοποθέτηση, ή αποδεχτείτε τον κίνδυνο γραπτώς.

Βήμα τρίτο: κάντε σωστά την αριθμητική του quorum

Αν χρειάζεται να επιβιώσετε δύο ταυτόχρονες βλάβες host, όπως συχνά θα έπρεπε ένα επίπεδο storage, χρειάζεστε πέντε μέλη σε πέντε ξεχωριστά domains, όχι τέσσερα: ένα τέταρτο μέλος προσθέτει κόστος χωρίς να προσθέτει ανοχή.

Βήμα τέταρτο: κάντε τον scheduler να επιβάλλει τον χάρτη

Ένας χάρτης που εξαρτάται από το να τοποθετεί κάποιος τα μηχανήματα σωστά θα είναι λάθος μετά την πρώτη συντήρηση. Κάντε την πλατφόρμα να τον επιβάλλει.

Σε έναν virtualization manager όπως το OLVM, δημιουργήστε ένα αρνητικό, enforcing affinity group ανά βαθμίδα, ώστε δύο μέλη να μην μπορούν ποτέ να τρέχουν στον ίδιο host, ακόμα και αφού ένας host αδειάσει.

Σε Kubernetes, χρησιμοποιήστε required pod anti-affinity και ένα PodDisruptionBudget για κάθε φόρτο με quorum:

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      [ { labelSelector: { matchLabels: { app: galera } },
          topologyKey: kubernetes.io/hostname } ]

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: { name: galera }
spec:
  minAvailable: 2
  selector:
    matchLabels: { app: galera }

Το anti-affinity κρατά τα μέλη σε διαφορετικούς κόμβους. Βάλτε labels στους κόμβους ανά chassis και προσθέστε έναν δεύτερο κανόνα σε εκείνο το label αν τα enclosures είναι domain. Το budget σημαίνει ότι μια κυλιόμενη ενημέρωση κόμβων δεν μπορεί ποτέ να εκδιώξει δεύτερο μέλος όσο ένα είναι ήδη εκτός. Ελέγξτε το αποτέλεσμα, όχι την πρόθεση:

kubectl get pods -l app=galera -o wide

Βήμα πέμπτο: το φύλλο δοκιμών μεταβίβασης

Τώρα αποδείξτε το. Για κάθε βαθμίδα, αφαιρέστε ένα μέλος όπως θα το έκανε μια πραγματική βλάβη, με την εφαρμογή συνδεδεμένη και πραγματική κίνηση να ρέει, και καταγράψτε τι συνέβη:

Ενέργεια	Αναμενόμενο	Μετρημένο	Τι είδαν οι clients
σταματήστε τον writer της βάσης δεδομένων	ο proxy μεταφέρει τις εγγραφές σε έναν επιζώντα	δευτερόλεπτα μέχρι να ξαναρχίσουν οι εγγραφές
σταματήστε το primary της cache	το Sentinel προάγει ένα replica	δευτερόλεπτα μέχρι την προαγωγή
ρίξτε έναν κόμβο edge	η floating διεύθυνση μετακινείται στον peer	δευτερόλεπτα, προς κάθε κατεύθυνση
σβήστε έναν host	τα μέλη του ξαναχτίζονται αλλού, το quorum κρατά
αποσυνδέστε μία διαδρομή συστοιχίας	η κίνηση storage συνεχίζει στην άλλη διαδρομή

Τρέξτε έναν probe με χρονοσήμανση από έξω σε κάθε δοκιμή, ώστε το «τι είδαν οι clients» να είναι μέτρηση:

while true; do
  printf '%s ' "$(date +%T.%N)"
  curl -s -o /dev/null -w '%{http_code} %{time_total}\n' https://app.example.com/health
  sleep 0.2
done | tee failover-$(date +%F).log

Μετά επαναφέρετε κάθε μέλος και καταγράψτε ότι επανεντάχθηκε καθαρά, ως replica του νέου primary και όχι ως αντίπαλός του. Μια δοκιμή που τελειώνει με δύο primaries έχει βρει το πιο σημαντικό σφάλμα του φύλλου.

Βήμα έκτο: βάλτε κάποιον άλλον να το επαληθεύσει

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

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

• Τα failure domains που θα επιβιώσετε, γραμμένα.
• Ένας χάρτης κάθε μέλους κάθε βαθμίδας απέναντι σε αυτά τα domains, χωρίς πλειοψηφία σε ένα domain.
• Μεγέθη quorum επιλεγμένα με αριθμητική, μόνο περιττοί αριθμοί.
• Anti-affinity και disruption budgets που τα επιβάλλει η πλατφόρμα, και ελέγχονται.
• Ένα φύλλο δοκιμών μεταβίβασης με μετρημένους χρόνους και αποτελέσματα από την πλευρά των clients για κάθε βαθμίδα.
• Ανεξάρτητη επαλήθευση απέναντι στη ζωντανή πλατφόρμα, όχι στις σημειώσεις.

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

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

Σχετικά: Κατασκευές πλατφορμών υψηλής διαθεσιμότητας · Βάσεις δεδομένων σε cluster με Percona XtraDB Cluster · Object caching με αυτόματο failover