Επιλέξτε διαθεσιμότητα μεταξύ ζωνών και περιοχών
ΟλοκληρώθηκεΣυγκρίνετε σχεδιασμούς υψηλής διαθεσιμότητας, Multi-AZ και multi-region. Ιχνηλατήστε ολόκληρη τη διαδρομή αιτήματος και δοκιμάστε την αστοχία που πρέπει να αντέχει κάθε σχεδιασμός.
Εκδότης TaigaΠώς γράφουμε
Ελέγξτε τι κατανοήσατεΔύο web replicas εκτελούνται σε διαφορετικές AZ. Και τα δύο απαιτούν την ίδια βάση δεδομένων σε μία AZ. Τι αποδεικνύει αυτό;Κάντε την άσκηση
Τι θα μάθετε
- Εξηγήστε τη διαφορά ανάμεσα σε Availability Zone και Region.
- Βρείτε κοινές εξαρτήσεις που ακυρώνουν έναν σχεδιασμό διαθεσιμότητας.
- Συγκρίνετε την επιχειρηματική αξία και το κόστος λειτουργίας ενός multi-region deployment.
Ξεκινήστε από την ενέργεια του χρήστη
Η υψηλή διαθεσιμότητα, ή HA, επιδιώκει να κρατά μια υπηρεσία χρηστική παρά τις αστοχίες συστατικών. Ορίστε τι σημαίνει χρηστική υπηρεσία πριν επιλέξετε αρχιτεκτονική. Μια σελίδα κρατήσεων που φορτώνεται ενώ όλα τα αιτήματα κράτησης αποτυγχάνουν δεν είναι διαθέσιμη υπηρεσία κρατήσεων.
Θέστε στόχο επιπέδου υπηρεσίας, ή SLO, για τη σημαντική ενέργεια. Ορίστε ποια αιτήματα μετρούν, τι σημαίνει επιτυχία και την περίοδο μέτρησης. Το SLA μιας υπηρεσίας cloud περιγράφει τη δέσμευση εκείνου του παρόχου. Δεν αποδεικνύει τη μετρημένη διαθεσιμότητα της εφαρμογής σας.
Ενδεικτικά, διαθεσιμότητα 99,9% με βάση τον χρόνο επιτρέπει 43,2 λεπτά μη διαθεσιμότητας σε μήνα 30 ημερών. Ένα SLO με βάση τα αιτήματα έχει διαφορετικό παρονομαστή. Κανένα από τα δύο μεγέθη δεν λέει πόσα δεδομένα μπορείτε να χάσετε ούτε εγγυάται μέγιστη διάρκεια μεμονωμένης διακοπής.
Κατανοήστε τα όρια αστοχίας
Μια AWS Availability Zone, ή AZ, είναι απομονωμένη τοποθεσία υποδομής μέσα σε μια Region. Μια Region περιέχει πολλές AZ. Ένας multi-region σχεδιασμός κατανέμει συστατικά του workload μεταξύ Regions. Άλλοι πάροχοι έχουν δικά τους όρια και συμπεριφορές υπηρεσιών· εξετάστε την επιλεγμένη υπηρεσία.
| Σχεδιασμός | Αστοχία που μπορεί να βοηθήσει να αντιμετωπιστεί | Τι εξακολουθεί να χρειάζεται σχεδιασμό |
|---|---|---|
| Πολλές διεργασίες σε μία AZ | Αστοχία διεργασίας ή host | Απώλεια AZ και κοινές εξαρτήσεις |
| Multi-AZ σε μία Region | Απώλεια AZ | Αστοχία Region, αλλοίωση δεδομένων και ανάκτηση |
| Πολλές Regions | Απώλεια Region | Δρομολόγηση, συνέπεια δεδομένων, δυναμικότητα και κοινές υπηρεσίες |
Αυτές είναι δυνατότητες σχεδιασμού, όχι εγγυήσεις διαθεσιμότητας. Μια ετικέτα δεν αποδεικνύει ότι κάθε απαιτούμενο συστατικό χρησιμοποιεί το επιδιωκόμενο όριο.
Ιχνηλατήστε ολόκληρη τη διαδρομή αιτήματος
Εξετάστε μια πλασματική υπηρεσία κρατήσεων. Τα web replicas λειτουργούν σε δύο AZ. Και τα δύο χρησιμοποιούν μία βάση δεδομένων και ένα εξερχόμενο gateway στην AZ A. Το gateway απαιτείται για την κλήση του παρόχου πληρωμών.
Αν η AZ A αποτύχει, το web replica στην AZ B μπορεί να παραμείνει υγιές ενώ η κράτηση εξακολουθεί να αποτυγχάνει. Η ομάδα πρέπει να αξιολογήσει τη βάση δεδομένων, τη διαδρομή δικτύου, τον πάροχο ταυτοτήτων, την εξάρτηση πληρωμών και τη δρομολόγηση. Εξετάστε τον πραγματικό τρόπο λειτουργίας της διαχειριζόμενης βάσης: replication, failover και συμπεριφορά ανάγνωσης διαφέρουν ανά προϊόν και διαμόρφωση.
Ελέγξτε επίσης τη δυναμικότητα. Οι πόροι που παραμένουν διαθέσιμοι πρέπει να χειρίζονται τον απαιτούμενο φόρτο. Ένας σχεδιασμός που βασίζεται στη δημιουργία δυναμικότητας κατά το περιστατικό εξαρτάται από quotas, διαθέσιμους πόρους και ενέργειες του control plane.
Εκτελέστε ελεγχόμενη άσκηση με καθορισμένο όριο, συνθήκες διακοπής και υπεύθυνο. Επαληθεύστε πλήρη κράτηση, μαζί με τη συμφωνία των στοιχείων πληρωμών. Καταγράψτε αποτυχημένα αιτήματα και τον χρόνο μέχρι την ανάκτηση χρήσιμης λειτουργίας.
Αποφασίστε αν άλλη Region λύνει το πρόβλημα
Η λειτουργία multi-region προσθέτει μεταφορά δεδομένων, διπλούς πόρους, συντονισμό deployments και λειτουργική εργασία. Το active/passive κρατά ένα περιβάλλον έτοιμο να δεχτεί κίνηση. Το active/active εξυπηρετεί κίνηση σε περισσότερα από ένα περιβάλλοντα. Η απαιτούμενη ετοιμότητα και συμπεριφορά δεδομένων διαφέρουν.
Για την υπηρεσία κρατήσεων, οι ταυτόχρονες εγγραφές εισάγουν ένα ερώτημα: μπορούν δύο Regions να πουλήσουν την ίδια θέση; Ορίστε ποιο σύστημα έχει τον τελικό λόγο για μια κράτηση και πώς συμπεριφέρεται η υπηρεσία όταν διακόπτεται το replication. Το «αντιγράψτε τη βάση δεδομένων» δεν είναι πλήρης απάντηση.
Ελέγξτε επιτρεπόμενες τοποθεσίες δεδομένων, κλειδιά κρυπτογράφησης, πιστοποιητικά, DNS, μυστικά και εξωτερικές υπηρεσίες. Μια κοινή αστοχία ταυτοτήτων ή μια προβληματική έκδοση μπορεί να επηρεάσει πολλές Regions. Οι περισσότερες τοποθεσίες δεν αφαιρούν κάθε κοινή αιτία.
Συνδέστε τη διαθεσιμότητα με την ανάκτηση
Η HA αντιμετωπίζει καθορισμένες αστοχίες κατά τη λειτουργία. Η ανάκτηση από καταστροφή επαναφέρει μια χρηστική υπηρεσία και τα δεδομένα της μετά από γεγονός που προκαλεί διακοπή. Μια υπηρεσία multi-region εξακολουθεί να χρειάζεται σχέδιο ανάκτησης για διαγραφή ή αλλοιωμένα δεδομένα.
Τεκμηριώστε τα επιλεγμένα σενάρια αστοχίας και εκείνα που αποδέχεται η επιχείρηση. Κρατήστε τα tests και τους ορισμούς υποδομής ευθυγραμμισμένα καθώς αλλάζει η εφαρμογή. Συνεχίστε με RTO, RPO και ανάκτηση από καταστροφή.
Κάντε την άσκηση
Μια πλασματική υπηρεσία κρατήσεων εκτελεί web replicas σε δύο AZ. Η βάση δεδομένων και το εξερχόμενο gateway βρίσκονται σε μία AZ. Σχεδιάστε τη διαδρομή αιτήματος. Αφαιρέστε αυτή την AZ στο χαρτί. Προσδιορίστε τι εξακολουθεί να λειτουργεί, τι αποτυγχάνει και ποιο test θα επαλήθευε το συμπέρασμά σας.
Λήψη φύλλου εργασίας (Markdown)Η κατάργηση αυτής της επιλογής διαγράφει όλη την πρόοδο που έχει αποθηκευτεί σε αυτόν τον browser.
Η πρόοδος παραμένει σε αυτό το πρόγραμμα περιήγησης. Χωρίς λογαριασμό ή παρακολούθηση.
Πηγές και πρόσθετη μελέτη
- AWS: Deploy the workload to multiple locations ↗
- AWS: Shared responsibility model for resiliency ↗
- Google SRE: Implementing SLOs ↗