Την 1η Μαρτίου, μια availability zone στην περιοχή me-central-1 της AWS, η mec1-az2, χτυπήθηκε από αυτό που η AWS περιέγραψε ως "objects that struck the data center, creating sparks and fire". Περίπου δεκαοκτώ ώρες αργότερα, μια δεύτερη ζώνη, η mec1-az3, έχασε επίσης ρεύμα. Η τρίτη, η mec1-az1, παρέμεινε όρθια καθ' όλη τη διάρκεια. Με δύο από τις τρεις ζώνες πληγμένες, το S3 και το DynamoDB άρχισαν να αστοχούν σε επίπεδο περιοχής, και η συμβουλή της AWS προς τους πελάτες, με τα ίδια της τα λόγια στο Health Dashboard, ήταν να "enact their disaster recovery plans and recover from remote backups into alternate AWS Regions, ideally in Europe". Η ανεξαρτησία των availability zones είναι σχεδιασμένη ενάντια σε βλάβες ρεύματος, βλάβες ψύξης και βλάβες δικτύου. Τον Μάρτιο συνάντησε μια αιτία ενάντια στην οποία δεν σχεδιάστηκε ποτέ, και η αιτία δεν ενδιαφερόταν για τη μηχανική.

Αυτό είναι το Μέρος 2 του Nothing Fails Alone. Το Μέρος 1 εξέτασε το συμβάν του Μαΐου στην us-east-1 και υποστήριξε ότι το όριο ζώνης άντεξε, και όντως άντεξε: μια βλάβη ψύξης σε ένα data hall έμεινε μέσα σε μία ζώνη, ακριβώς όπως σχεδιάστηκε, και η διακοπή που ακολούθησε χτίστηκε από τον πελάτη. Εκείνο το επιχείρημα ήταν σωστό, και απάντησε σε μια συγκεκριμένη ερώτηση: συγκρατεί η απομόνωση AZ τους τρόπους αστοχίας ενάντια στους οποίους είναι σχεδιασμένη; Το συμβάν του Μαρτίου στην me-central-1 θέτει μια διαφορετική ερώτηση. Συνέβη πριν γραφτεί το Μέρος 1, και τότε ήταν εύκολο να το κατατάξει κανείς ως ειδική περίπτωση πολέμου, μια υποσημείωση πολεμικής πράξης χωρίς μαθήματα για τη φυσιολογική αρχιτεκτονική. Το συμβάν του Μαΐου είναι αυτό που έκανε ορατό το γενικό σχήμα: το Μέρος 1 αφορούσε το τι προστατεύει το όριο ζώνης, και αυτό το μέρος αφορά το τι δεν μπορεί να προστατεύσει, δηλαδή οποιαδήποτε αιτία φτάνει σε περισσότερες από μία ζώνες. Αυτές οι αιτίες υπάρχουν και σε καιρό ειρήνης. Ο πόλεμος απλώς συμπύκνωσε την επίδειξη σε δύο ημέρες.

Τι πραγματικά συνέβη στην me-central-1

Το συμβάν άνοιξε στο AWS Health Dashboard στις 4:51 AM PST την 1η Μαρτίου ως διερεύνηση για "issues with AWS services in the ME-CENTRAL-1 Region", και γρήγορα στένεψε σε ένα "localized power issue" σε μία μόνο availability zone, την mec1-az2. Το log του dashboard είναι ασυνήθιστα ειλικρινές, και στις 9:41 AM PST εξήγησε γιατί κόπηκε το ρεύμα: "At around 4:30 AM PST, one of our Availability Zones (mec1-az2) was impacted by objects that struck the data center, creating sparks and fire. The fire department shut off power to the facility and generators as they worked to put out the fire." Την επόμενη μέρα η AWS ονομάτισε την αιτία, σε μια ενημέρωση που το The Register κάλυψε την ίδια μέρα: επιθέσεις με drone, μέρος της σύρραξης στη Μέση Ανατολή. "In the UAE, two of our facilities were directly struck", και οι επιθέσεις "caused structural damage, disrupted power delivery to our infrastructure, and in some cases required fire suppression activities that resulted in additional water damage".

Καθ' όλη την πρώτη μέρα, το συμβάν έμοιαζε με σχολικό παράδειγμα συμβάντος μίας ζώνης, και η AWS το είπε στην ίδια ενημέρωση των 9:41 AM: "Customers who were running their applications redundantly across the AZs are not impacted by this event." Το Multi-AZ ήταν, εκείνη την ώρα, η σωστή και επαρκής απάντηση, και μια ενημέρωση λιγότερο από μία ώρα νωρίτερα κουβαλούσε μια επιφύλαξη που έχετε ξαναδιαβάσει αν διαβάσατε το Μέρος 1: λόγω αυξημένης ζήτησης στις ανεπηρέαστες ζώνες, "customers may experience longer than usual provisioning times". Η ίδια φράση που η AWS θα δημοσίευε κατά τη διάρκεια του συμβάντος του Μαΐου στην us-east-1, το συμβάν που κάλυψε το Μέρος 1 πριν από δύο εβδομάδες, παρόλο που στο ημερολόγιο ο Μάρτιος προηγήθηκε. Το μαζικό failover στις εναπομείνασες ζώνες είναι ένα thundering herd παντού, σε κάθε περιοχή, σε κάθε συμβάν.

Έπειτα, στις 10:46 PM PST, περίπου δεκαοκτώ ώρες μετά την πρώτη επίθεση: "a localized power issue has affected another Availability Zone in the ME-CENTRAL-1 Region (mec1-az3) ... At this point it is not possible to launch new instances in the region ... Other AWS Services, such as DynamoDB and S3 are also experiencing significant error rates and latencies." Δύο από τις τρεις ζώνες εκτός, και η αστοχία είχε αναρριχηθεί εντελώς έξω από το επίπεδο των ζωνών.

Οι δεκαοκτώ ώρες δεν είναι ταυτόχρονες, και αυτό είναι το ζητούμενο

Οι δύο ζώνες δεν έπεσαν μαζί. Έπεσαν με διαφορά περίπου δεκαοκτώ ωρών, από την ίδια αιτία. Αυτή η διάκριση είναι όλο το επιχείρημα αυτού του άρθρου, οπότε αξίζει να είμαστε ακριβείς γι' αυτήν. Η ανεξαρτησία των ζωνών είναι ένας ισχυρισμός πιθανότητας: η AWS σχεδιάζει τις ζώνες πάνω σε ξεχωριστό ρεύμα, ξεχωριστή ψύξη, ξεχωριστές πλημμυρικές ζώνες και ξεχωριστές διαδρομές δικτύου, ώστε οι εσωτερικές βλάβες μίας εγκατάστασης, ένα χαλασμένο chiller, ένας χαλασμένος μετασχηματιστής, ένα κακό switch fabric, να μένουν μέσα της και να μη συμπίπτουν με τις εσωτερικές βλάβες μιας άλλης. Με τους δικούς του όρους, ο Μάρτιος δεν άλλαξε τίποτα. Καμία ζώνη δεν έριξε την άλλη. Δεν υπήρχε κοινός μετασχηματιστής, καμία αλυσιδωτή εξάρτηση. Η μηχανική της απομόνωσης λειτούργησε από την αρχή μέχρι το τέλος.

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

Γι' αυτό αποτυγχάνει η πλαισίωση της ειδικής περίπτωσης πολέμου. Τα drones είναι εξωτικά, η κοινή μητροπολιτική υποδομή δεν είναι. Κάθε multi-AZ περιοχή συγκεντρώνει τις ζώνες της εντός μονοψήφιων milliseconds η μία από την άλλη, που στην πράξη σημαίνει το ίδιο blast radius κλίμακας πόλης για τον καιρό, τις υπηρεσίες κοινής ωφέλειας και την πολιτική. Το συμβάν του Μαρτίου είναι το ακραίο άκρο μιας οικογένειας αιτιών που περιλαμβάνει κάθε γεγονός αρκετά μεγάλο ώστε να ονομαστεί από την πόλη στην οποία συνέβη. Όταν το InfoQ ανέλυσε το συμβάν αργότερα εκείνον τον μήνα υπό τον τίτλο "War in Iran Damages Multiple AWS Data Centers, Challenging Multi-AZ Assumptions", η συζήτηση της κοινότητας που συνόψιζε είχε ήδη προσπεράσει τα drones προς τη γενική περίπτωση: οι ζώνες είναι ένα σύμπλεγμα κτιρίων στην ίδια πόλη, και οι υποθέσεις που αξίζει να αμφισβητηθούν αφορούν οτιδήποτε μπορεί να φτάσει σε μια πόλη.

Όταν η ίδια η περιοχή είναι το failure domain

Η πιο διδακτική ενημέρωση σε όλο το log ήρθε στις 2:53 AM PST στις 2 Μαρτίου, όταν η AWS εξήγησε τι κάνουν δύο χαμένες ζώνες στο S3: "Amazon S3 is a regional service and designed to withstand the total loss of a single Availability Zone ... As the second AZ became impaired, S3 error rates increased. With two Availability Zones significantly impacted, customers are seeing high failure rates for data ingest and egress."

Διαβάστε αυτή την πρόταση σαν έγγραφο αρχιτεκτονικής, επειδή αυτό είναι. Το S3 και το DynamoDB είναι οι υπηρεσίες για τις οποίες δεν σχεδιάζετε για αστοχία ζώνης, επειδή το κάνει η AWS για εσάς, αναπαράγοντας μεταξύ ζωνών ώστε η απώλεια μίας ζώνης να είναι αόρατη. Αυτός ο σχεδιασμός έχει μια δηλωμένη ανοχή: μία ζώνη. Η δεύτερη ζώνη την ξεπέρασε, και οι υπηρεσίες πάνω στις οποίες στηριζόταν κάθε "resilient" αρχιτεκτονική στην περιοχή, για την κατάσταση, για τα backups, για τα δεδομένα συντονισμού του ίδιου του failover, άρχισαν να αρνούνται αναγνώσεις και εγγραφές σε επίπεδο περιοχής. Η multi-AZ εφαρμογή σας δεν έχασε απλώς τα instances της, έχασε το περιφερειακό υπόστρωμα πάνω στο οποίο σχεδίαζε να ανακτηθεί. Η mec1-az1 ήταν υγιής, και δεν είχε σημασία, επειδή μια υγιής ζώνη συνδεδεμένη με ένα πληγμένο περιφερειακό control plane είναι ένα δωμάτιο με αναμμένα φώτα σε ένα κτίριο χωρίς υδραυλικά. Αυτό είναι το κομμάτι που το multi-AZ δεν μπορεί να απαντήσει. Οι περιφερειακές υπηρεσίες χτίζονται πάνω στις ίδιες τρεις ζώνες με εσάς, και η ανοχή τους στη συσχετισμένη απώλεια ζωνών είναι ένας αριθμός που διάλεξε η AWS, όχι ένας αριθμός που διαλέξατε εσείς.

"Ideally in Europe"

Μέχρι τις 6:22 AM PST στις 2 Μαρτίου, η καθοδήγηση της AWS είχε φτάσει στην πιο ωμή της πρόταση: "We recommend customers enact their disaster recovery plans and recover from remote backups into alternate AWS Regions, ideally in Europe."

Αυτή η πρόταση αξίζει μια πιο αργή ανάγνωση από αυτήν που έλαβε τον Μάρτιο. Πρώτον, ο πάροχος του οποίου είναι η περιοχή είπε στους πελάτες να την εγκαταλείψουν. Αυτή είναι η οροφή της εντός-περιοχής πλεονασματικότητας, δηλωμένη από τον προμηθευτή: υπάρχει μια κατηγορία συμβάντος για την οποία η σωστή ποσότητα me-central-1 στο σχέδιο ανάκαμψής σας είναι μηδέν, και μαθαίνετε σε ποια κατηγορία βρίσκεστε στη μέση του συμβάντος, από ένα dashboard. Δεύτερον, το "ideally in Europe" κάνει μια σιωπηλή, προσεκτική δουλειά. Η πλησιέστερη εναλλακτική, η me-south-1 στο Μπαχρέιν, είναι λίγο πιο πέρα και θα ήταν η αντανακλαστική επιλογή DR για λόγους latency, και μια εγκατάσταση εκεί είχε επηρεαστεί από μια κοντινή επίθεση στην ίδια εκστρατεία. Η AWS έλεγε στους πελάτες, χωρίς να το ξεκαθαρίζει, ότι η συσχετισμένη αιτία είχε μια γεωγραφία, και ότι μια χρήσιμη περιοχή ανάκαμψης είναι μία εκτός αυτής της γεωγραφίας, όχι απλώς εκτός του ARN της περιοχής. Η απόσταση από την πρωτεύουσα εγκατάστασή σας δεν είναι ένα κουτάκι συμμόρφωσης, είναι ένα στοίχημα για το πόσο μακριά ταξιδεύουν οι συσχετισμένες αιτίες σας. Διαλέξτε την περιοχή DR σας ρωτώντας τι θα μπορούσε εύλογα να χτυπήσει και τις δύο, όχι τι κρατά όμορφο το latency της αναπαραγωγής.

Τρίτον, η συμβουλή λειτουργεί μόνο για τους πελάτες που μπορούσαν να την ακολουθήσουν. Το "Recover from remote backups" προϋποθέτει ότι τα απομακρυσμένα backups υπάρχουν, δημιουργημένα πριν την 1η Μαρτίου, επειδή το ίδιο log ενημερώσεων δείχνει το S3 "data ingest and egress" να αστοχεί σε επίπεδο περιοχής κατά τη διάρκεια του συμβάντος. Η αντιγραφή των δεδομένων σας έξω από μια περιοχή είναι δραστηριότητα καιρού ειρήνης. Μέχρι να τη συμβουλεύει ο πάροχος, το παράθυρο για να ξεκινήσετε έχει κλείσει.

Αρκετοί μήνες

Η τελευταία ενημέρωση του συμβάντος, με ημερομηνία 30 Απριλίου, είναι μία παράγραφος και τελειώνει την ιστορία χωρίς να την τελειώνει: η περιοχή "has suffered damage as a result of the conflict in the Middle East and is currently unable to reliably support customer applications", οι πελάτες πρέπει να "migrate all accessible resources to other Regions and restore inaccessible resources from remote backups as soon as possible", οι λειτουργίες χρέωσης αναστέλλονται, και η ανάκαμψη "is expected to take several months".

Βάλτε το απέναντι σε ένα τυπικό έγγραφο DR. Ένα RTO γράφεται ως διάρκεια, και σχεδόν κάθε RTO που έχω εξετάσει υποθέτει σιωπηλά ότι ο στόχος ανάκτησης είναι το μέρος όπου ήδη βρίσκεστε: επαναφέρετε το snapshot, ξαναξεκινάτε τον στόλο, ίδια περιοχή, ώρες στη χειρότερη. Το "several months" δεν καταπονεί αυτόν τον αριθμό, διαγράφει τον άξονα πάνω στον οποίο γράφτηκε. Αν η περιοχή δεν επιστρέφει αυτό το τρίμηνο, ο πραγματικός σας χρόνος ανάκτησης είναι όσο διαρκεί ένα ψυχρό cross-region ξαναχτίσιμο, μαζί με τα κομμάτια που κανείς δεν πρόβαρε: IAM και δικτύωση ξαναδημιουργημένα από κώδικα που ελπίζετε ότι έχετε, δεδομένα επαναφερμένα από replicas που ελπίζετε ότι φτιάξατε, DNS που αλλάζει, χωρητικότητα που βρέθηκε σε μια περιοχή προορισμού που απορροφά ταυτόχρονα την έξοδο όλων των άλλων. Για τις ομάδες με cross-region αναπαραγωγή ήδη σε ροή, ο Μάρτιος ήταν μια κακή εβδομάδα. Για τις ομάδες των οποίων το σχέδιο DR ήταν εντός-περιοχής snapshots, ήταν ένα έργο μετανάστευσης που ανακοινώθηκε από το πυροβολικό.

Το lab: σε ποιες φυσικές ζώνες βρίσκεστε πραγματικά;

Το Μέρος 1 έκλεισε την ενότητα του lab σημειώνοντας ότι οι αναφορές συμβάντων της AWS ονομάζουν τις ζώνες με ID, use1-az4, και ότι χωρίς την αντιστοίχιση ID προς όνομα δεν μπορείτε να πείτε αν αυτό ήταν η δική σας us-east-1a. Ο Μάρτιος είναι το συμβάν όπου αυτό παύει να είναι ασήμαντη λεπτομέρεια. Το dashboard είπε mec1-az2, μετά mec1-az3. Για να ξέρετε αν τα workloads σας βρίσκονταν στις χτυπημένες ζώνες ή στην επιζήσασα, έπρεπε να επιλύσετε αυτά τα IDs απέναντι στον λογαριασμό σας, στη μέση του συμβάντος, επειδή ένα όνομα ζώνης όπως me-central-1a είναι ένα alias εμβέλειας λογαριασμού: η AWS αναθέτει γράμματα σε φυσικές ζώνες ανεξάρτητα ανά λογαριασμό, οπότε οι me-central-1a δύο λογαριασμών είναι συνήθως διαφορετικές φυσικές ζώνες. Το "είμαστε απλωμένοι σε a, b και c" είναι μια δήλωση για την ονοματοδοσία του λογαριασμού σας, όχι για τη φυσική τοποθέτηση.

Το lab αυτού του μέρους, το 02-az-id-truth, είναι σκόπιμα το μικρότερο της σειράς: ένα μοναδικό read-only script του οποίου οι μόνες κλήσεις API είναι DescribeAvailabilityZones και GetCallerIdentity, η δεύτερη απλώς για να επισημάνει την έξοδο. Τυπώνει την αντιστοίχιση ονόματος προς ID για τον τρέχοντα λογαριασμό και region. Αυτή είναι η πραγματική έξοδος για έναν από τους λογαριασμούς μου:

$ python3 az_ids.py --region us-east-1
Region: us-east-1

ZONE NAME  | ZONE ID  | STATE
---------------------------------
us-east-1a | use1-az1 | available
us-east-1b | use1-az2 | available
us-east-1c | use1-az4 | available
us-east-1d | use1-az6 | available
us-east-1e | use1-az3 | available
us-east-1f | use1-az5 | available
...

Σε αυτόν τον λογαριασμό, η use1-az4, η ζώνη στην αναφορά συμβάντος του Μαΐου, είναι η us-east-1c. Ένας μηχανικός εδώ που διάβασε "use1-az4" τον Μάιο και έριξε μια ματιά σε ένα διάγραμμα με ετικέτα "us-east-1a" θα είχε χαλαρώσει για τη λάθος ζώνη και θα είχε ανησυχήσει για μια υγιή. Το script δέχεται επίσης --compare <profile>, που διαβάζει την αντιστοίχιση ενός δεύτερου λογαριασμού στο ίδιο region και τυπώνει τις δύο δίπλα-δίπλα με μια ετυμηγορία ανά όνομα για το αν επιλύονται στην ίδια φυσική ζώνη, και μετά μετρά τις αναντιστοιχίες, το ίδιο όνομα που επιλύεται σε διαφορετικά IDs μεταξύ λογαριασμών είναι η φυσιολογική περίπτωση, όχι η εξαίρεση. Ένα κοινό runbook που λέει "evacuate us-east-1a" κάνει διαφορετικά πράγματα σε διαφορετικούς λογαριασμούς. Τα runbooks, οι αποφάσεις τοποθέτησης και οι αναζητήσεις συμβάντων ανήκουν στα zone IDs. Υπάρχει ένα --json flag για την τροφοδότηση της αντιστοίχισης σε εργαλεία inventory, και ο κωδικός εξόδου είναι 0 όποτε ολοκληρώνεται η εκτέλεση, κρατώντας το 2 για εκτελέσεις που δεν μπορούν να συμβούν καθόλου: χωρίς boto3, χωρίς credentials, χωρίς region, άγνωστο profile, ή αν αστοχήσει η ίδια η κλήση describe.

Τρόποι αστοχίας και τι να προσέχετε

Πρώτα να είμαστε ειλικρινείς για τα όρια: ένας πελάτης δεν μπορεί να σχεδιάσει την me-central-1 έξω από έναν πόλεμο. Τίποτα στο Terraform σας δεν αποτρέπει τη συσχετισμένη αιτία, αυτό που ελέγχετε είναι αν σας βρει με τα δεδομένα σας ήδη αλλού. Η λίστα παρακολούθησης που προκύπτει από τον Μάρτιο είναι σύντομη. Απαριθμήστε τις αιτίες που φτάνουν σε όλες τις ζώνες σας ταυτόχρονα: την κοινή μητρόπολη, το κοινό δίκτυο ρεύματος, τον κοινό καιρό, την κοινή δικαιοδοσία, και αντιμετωπίστε την απάντηση ως την πραγματική σας πιθανότητα απώλειας περιοχής, που είναι χαμηλή αλλά όχι το μηδέν που υπέθεσαν σιωπηλά τα μαθηματικά των ζωνών. Κρατήστε cross-region backups για οτιδήποτε δεν μπορείτε να αναπαραγάγετε, σε μια περιοχή επιλεγμένη επειδή είναι εκτός της συσχετισμένης γεωγραφίας, και δοκιμάστε την επαναφορά, επειδή η εκδοχή αυτής της δοκιμής τον Μάρτιο είχε μέσα μια πυροσβεστική. Γράψτε τα RTOs δύο φορές, μία για εντός-περιοχής ανάκτηση και μία υποθέτοντας ότι η περιοχή έχει χαθεί για ένα τρίμηνο, και βάλτε τον δεύτερο αριθμό μπροστά σε όποιον κατέχει τον κίνδυνο. Και κρατήστε μια απογραφή των φυσικών zone IDs σας ανά λογαριασμό, επειδή όταν η επόμενη αναφορά πει ένα zone ID, η στιγμή για να μάθετε την αντιστοίχισή σας δεν είναι κατά τη διάρκεια του συμβάντος. Το όριο ζώνης είναι πραγματικό, και το Μέρος 1 το έδειξε να αντέχει. Ο Μάρτιος έδειξε το πράγμα πάνω από αυτό: οι ζώνες μπορούν να είναι τέλεια απομονωμένες η μία από την άλλη και ακόμα να μην είναι απομονωμένες από τον κόσμο.

Διαβάστε στη συνέχεια

  • Το Μέρος 1 αυτής της σειράς: AZ Isolation Held. Your Architecture Didn't., το συμβάν του Μαΐου στην us-east-1 όπου το όριο λειτούργησε και η διακοπή χτίστηκε πάνω του.
  • Το Μέρος 3 αυτής της σειράς: The Fix Shares Fate, για το τι έχει κοινό το σχέδιο ανάκαμψής σας με το σχέδιο όλων των άλλων.
  • Cross-Region Inference: Cheap Resilience or Residency Trap? στο ercan.ai: το ίδιο trade-off ένα επίπεδο πιο πάνω, όταν αυτό που πρέπει να επιβιώσει από μια περιοχή είναι ένα AI workload και ο περιορισμός είναι το πού επιτρέπεται να πάνε τα δεδομένα σας.
  • Το συνοδευτικό repo: nothing-fails-alone, όλα τα labs αυτής της σειράς, read-only εκ σχεδιασμού.

Για συμβουλευτική σε AWS, cloud αρχιτεκτονική, επισκοπήσεις ανθεκτικότητας, και platform δουλειά, ξεκινήστε από το ercanermis.com.

Αναφορές