Γεια σας αναγνώστες Habr! Στο τελευταίο άρθρο, μιλήσαμε για ένα απλό μέσο αποκατάστασης από καταστροφή στα συστήματα αποθήκευσης AERODISK ENGINE - αναπαραγωγή. Σε αυτό το άρθρο, θα βουτήξουμε σε ένα πιο περίπλοκο και ενδιαφέρον θέμα - ένα metrocluster, δηλαδή ένα αυτοματοποιημένο εργαλείο προστασίας από καταστροφές για δύο κέντρα δεδομένων που επιτρέπει στα κέντρα δεδομένων να λειτουργούν σε ενεργή-ενεργή λειτουργία. Θα πούμε, θα δείξουμε, θα σπάσουμε και θα φτιάξουμε.
Ως συνήθως, στην αρχή της θεωρίας
Ένα metrocluster είναι ένα σύμπλεγμα που χωρίζεται σε πολλές τοποθεσίες μέσα σε μια πόλη ή περιοχή. Η λέξη "cluster" μας υποδηλώνει ξεκάθαρα ότι το σύμπλεγμα είναι αυτοματοποιημένο, δηλαδή η εναλλαγή των κόμβων συμπλέγματος σε περίπτωση αστοχιών (failover) γίνεται αυτόματα.
Εδώ έγκειται η κύρια διαφορά μεταξύ ενός metrocluster και της κανονικής αναπαραγωγής. Αυτοματοποίηση λειτουργιών. Δηλαδή, σε περίπτωση ορισμένων περιστατικών (αστοχία του κέντρου δεδομένων, θραύση καναλιών κ.λπ.), το σύστημα αποθήκευσης θα εκτελέσει ανεξάρτητα τις απαραίτητες ενέργειες προκειμένου να διατηρήσει τη διαθεσιμότητα των δεδομένων. Όταν χρησιμοποιείτε κανονικά αντίγραφα, αυτές οι ενέργειες εκτελούνται εξ ολοκλήρου ή εν μέρει με μη αυτόματο τρόπο από τον διαχειριστή.
Τι κάνει;
Ο κύριος στόχος που επιδιώκεται από πελάτες που χρησιμοποιούν ορισμένες υλοποιήσεις metrocluster είναι η ελαχιστοποίηση του RTO (Recovery Time Objective). Δηλαδή, να ελαχιστοποιηθεί ο χρόνος ανάκτησης των υπηρεσιών πληροφορικής μετά από μια αστοχία. Εάν χρησιμοποιείτε συμβατική αναπαραγωγή, τότε ο χρόνος ανάκτησης θα είναι πάντα μεγαλύτερος από τον χρόνο ανάκτησης με ένα σύμπλεγμα μετρό. Γιατί; Πολύ απλό. Ο διαχειριστής πρέπει να βρίσκεται στο χώρο εργασίας και να αλλάζει την αναπαραγωγή χειροκίνητα, ενώ το σύμπλεγμα του μετρό το κάνει αυτόματα.
Εάν δεν έχετε ειδικό διαχειριστή που δεν κοιμάται, δεν τρώει, δεν καπνίζει ή αρρωσταίνει, αλλά παρακολουθεί την κατάσταση του συστήματος αποθήκευσης 24 ώρες την ημέρα, τότε δεν υπάρχει τρόπος να εγγυηθείτε ότι ο διαχειριστής θα είναι διαθέσιμος για χειροκίνητη εναλλαγή κατά τη διάρκεια μιας βλάβης.
Αντίστοιχα, το RTO ελλείψει συμπλέγματος μετρό ή αθάνατου διαχειριστή του 99ου επιπέδου υπηρεσίας υπηρεσίας διαχειριστών θα ισούται με το άθροισμα του χρόνου μεταγωγής όλων των συστημάτων και τη μέγιστη χρονική περίοδο μετά την οποία ο διαχειριστής είναι εγγυημένος ότι θα ξεκινήσει να εργάζεται με το σύστημα αποθήκευσης και τα σχετικά συστήματα.
Έτσι, καταλήγουμε στο προφανές συμπέρασμα ότι το metrocluster θα πρέπει να χρησιμοποιείται εάν η απαίτηση για RTO είναι λεπτά, όχι ώρες ή ημέρες. Δηλαδή, σε περίπτωση χειρότερης πτώσης στο κέντρο δεδομένων, το τμήμα IT πρέπει να παρέχει στην επιχείρηση χρόνο για να αποκαταστήσει την πρόσβαση σε υπηρεσίες πληροφορικής μέσα σε λίγα λεπτά ή και δευτερόλεπτα.
Πώς λειτουργεί;
Στο χαμηλότερο επίπεδο, το metrocluster χρησιμοποιεί τον μηχανισμό σύγχρονης αναπαραγωγής δεδομένων που περιγράψαμε στο προηγούμενο άρθρο (βλ. παρακάτω). ). Δεδομένου ότι η αναπαραγωγή είναι σύγχρονη, οι απαιτήσεις για αυτήν είναι κατάλληλες, ή μάλλον:
- ίνα ως φυσική, 10 gigabit ethernet (ή υψηλότερη).
- η απόσταση μεταξύ των κέντρων δεδομένων δεν υπερβαίνει τα 40 χιλιόμετρα.
- Καθυστέρηση οπτικού καναλιού μεταξύ κέντρων δεδομένων (μεταξύ συστημάτων αποθήκευσης) έως 5 χιλιοστά του δευτερολέπτου (καλύτερα 2).
Όλες αυτές οι απαιτήσεις έχουν συμβουλευτικό χαρακτήρα, δηλαδή το σύμπλεγμα του μετρό θα λειτουργεί ακόμη και αν δεν πληρούνται αυτές οι απαιτήσεις, αλλά πρέπει να γίνει κατανοητό ότι οι συνέπειες της μη συμμόρφωσης με αυτές τις απαιτήσεις ισοδυναμούν με την επιβράδυνση της λειτουργίας και των δύο συστημάτων αποθήκευσης στο σύμπλεγμα του μετρό.
Έτσι, ένα σύγχρονο αντίγραφο χρησιμοποιείται για τη μεταφορά δεδομένων μεταξύ συστημάτων αποθήκευσης, αλλά πώς αλλάζουν αυτόματα τα αντίγραφα και, το πιο σημαντικό, πώς να αποφευχθεί η διαίρεση του εγκεφάλου; Για να γίνει αυτό, στο παραπάνω επίπεδο, χρησιμοποιείται μια πρόσθετη οντότητα - ο διαιτητής.
Πώς λειτουργεί ένας διαιτητής και ποιο είναι το καθήκον του;
Ο διαιτητής είναι μια μικρή εικονική μηχανή ή ένα σύμπλεγμα υλικού που πρέπει να εκκινηθεί σε μια τρίτη τοποθεσία (για παράδειγμα, σε ένα γραφείο) και να παρέχει πρόσβαση στον χώρο αποθήκευσης μέσω ICMP και SSH. Μετά την εκκίνηση, ο διαιτητής θα πρέπει να ορίσει την IP και, στη συνέχεια, να καθορίσει τη διεύθυνσή της από την πλευρά αποθήκευσης, συν τις διευθύνσεις των τηλεχειριστηρίων που συμμετέχουν στο σύμπλεγμα του μετρό. Μετά από αυτό, ο διαιτητής είναι έτοιμος να πάει.
Ο διαιτητής παρακολουθεί συνεχώς όλα τα συστήματα αποθήκευσης στο σύμπλεγμα του μετρό και σε περίπτωση που ένα συγκεκριμένο σύστημα αποθήκευσης δεν είναι διαθέσιμο, μετά την επιβεβαίωση της μη διαθεσιμότητας από άλλο μέλος του συμπλέγματος (ένα από τα "ζωντανά" συστήματα αποθήκευσης), αποφασίζει να ξεκινήσει τη διαδικασία εναλλαγής κανόνων αναπαραγωγής και χαρτογράφησης.
Ένα πολύ σημαντικό σημείο. Ο διαιτητής πρέπει πάντα να βρίσκεται σε τοποθεσία διαφορετική από αυτή στην οποία βρίσκονται τα συστήματα αποθήκευσης, δηλαδή, ούτε στο DPC 1, όπου βρίσκεται ο χώρος αποθήκευσης 1, ούτε στο DPC 2, όπου είναι εγκατεστημένος ο χώρος αποθήκευσης 2.
Γιατί; Γιατί μόνο έτσι μπορεί ο διαιτητής, με τη βοήθεια ενός από τα σωζόμενα συστήματα αποθήκευσης, να προσδιορίσει ξεκάθαρα και με ακρίβεια την πτώση οποιουδήποτε από τους δύο χώρους όπου είναι εγκατεστημένα τα συστήματα αποθήκευσης. Οποιοσδήποτε άλλος τρόπος τοποθέτησης διαιτητή μπορεί να οδηγήσει σε διχασμό.
Τώρα ας βουτήξουμε στις λεπτομέρειες της δουλειάς του διαιτητή.
Αρκετές υπηρεσίες εκτελούνται στον διαιτητή που εξετάζουν συνεχώς όλους τους ελεγκτές αποθήκευσης. Εάν το αποτέλεσμα της δημοσκόπησης διαφέρει από το προηγούμενο (διαθέσιμο/μη διαθέσιμο), τότε γράφεται σε μια μικρή βάση δεδομένων που λειτουργεί και στον διαιτητή.
Εξετάστε τη λογική του διαιτητή με περισσότερες λεπτομέρειες.
Βήμα 1. Προσδιορισμός μη διαθεσιμότητας. Ένα συμβάν που σηματοδοτεί μια αποτυχία συστήματος αποθήκευσης είναι η απουσία ping και από τους δύο ελεγκτές του ίδιου συστήματος αποθήκευσης για 5 δευτερόλεπτα.
Βήμα 2. Έναρξη της διαδικασίας εναλλαγής. Αφού ο διαιτητής συνειδητοποίησε ότι ένα από τα συστήματα αποθήκευσης δεν είναι διαθέσιμο, στέλνει ένα αίτημα στο "ζωντανό" σύστημα αποθήκευσης προκειμένου να βεβαιωθεί ότι το "νεκρό" σύστημα αποθήκευσης είναι πραγματικά νεκρό.
Αφού λάβει μια τέτοια εντολή από τον διαιτητή, το δεύτερο (ζωντανό) σύστημα αποθήκευσης ελέγχει επιπλέον τη διαθεσιμότητα του πεσμένου πρώτου συστήματος αποθήκευσης και, εάν όχι, στέλνει στον διαιτητή επιβεβαίωση της εικασίας του. Το SHD, πράγματι, δεν είναι διαθέσιμο.
Μετά τη λήψη αυτής της επιβεβαίωσης, ο διαιτητής ξεκινά μια απομακρυσμένη διαδικασία για την εναλλαγή της αναπαραγωγής και την ανύψωση της αντιστοίχισης σε εκείνα τα αντίγραφα που ήταν ενεργά (κύρια) στο σύστημα αποθήκευσης που πέφτει και στέλνει μια εντολή στο δεύτερο σύστημα αποθήκευσης για να κάνει αυτά τα αντίγραφα από δευτερεύοντα σε πρωτεύοντα και να αυξήσει την αντιστοίχιση. Λοιπόν, το δεύτερο σύστημα αποθήκευσης, αντίστοιχα, εκτελεί αυτές τις διαδικασίες, μετά τις οποίες παρέχει πρόσβαση στα χαμένα LUN από τον εαυτό του.
Γιατί απαιτείται πρόσθετη επαλήθευση; Για απαρτία. Δηλαδή, η πλειοψηφία του συνολικού περιττού (3) αριθμού μελών του συμπλέγματος πρέπει να επιβεβαιώσει την πτώση ενός από τους κόμβους του συμπλέγματος. Μόνο τότε αυτή η απόφαση θα είναι ακριβώς σωστή. Αυτό είναι απαραίτητο για να αποφευχθεί η λανθασμένη εναλλαγή και, κατά συνέπεια, ο διαχωρισμός του εγκεφάλου.
Το βήμα 2 διαρκεί περίπου 5-10 δευτερόλεπτα, επομένως, λαμβάνοντας υπόψη τον χρόνο που απαιτείται για τον προσδιορισμό της μη διαθεσιμότητας (5 δευτερόλεπτα), εντός 10-15 δευτερολέπτων μετά την αποτυχία, τα LUN με πεσμένο σύστημα αποθήκευσης θα είναι αυτόματα διαθέσιμα για εργασία με ζωντανή αποθήκευση.
Είναι σαφές ότι για να αποφύγετε την αποσύνδεση με τους οικοδεσπότες, πρέπει επίσης να φροντίσετε για τη σωστή ρύθμιση των timeouts στους οικοδεσπότες. Το προτεινόμενο χρονικό όριο είναι τουλάχιστον 30 δευτερόλεπτα. Αυτό εμποδίζει τον κεντρικό υπολογιστή να διακόψει τη σύνδεση με τον αποθηκευτικό χώρο κατά τη διάρκεια ενός φορτίου ανακατεύθυνσης και μπορεί να διασφαλίσει ότι δεν υπάρχει διακοπή εισόδου/εξόδου.
Περιμένετε λίγο, αποδεικνύεται ότι αν όλα είναι καλά με το σύμπλεγμα του μετρό, γιατί χρειαζόμαστε καθόλου τακτική αναπαραγωγή;
Στην πραγματικότητα, όλα δεν είναι τόσο απλά.
Εξετάστε τα πλεονεκτήματα και τα μειονεκτήματα του metrocluster
Έτσι, συνειδητοποιήσαμε ότι τα προφανή πλεονεκτήματα του metrocluster σε σύγκριση με τη συμβατική αναπαραγωγή είναι:
- Πλήρης αυτοματοποίηση, εξασφαλίζοντας ελάχιστο χρόνο αποκατάστασης σε περίπτωση καταστροφής.
- Και αυτό είναι :-).
Και τώρα, προσοχή, μειονεκτήματα:
- Κόστος λύσης. Αν και το metrocluster στα συστήματα Aerodisk δεν απαιτεί πρόσθετη άδεια χρήσης (χρησιμοποιείται η ίδια άδεια όπως και για το αντίγραφο), το κόστος της λύσης θα είναι ακόμα υψηλότερο από τη χρήση σύγχρονης αναπαραγωγής. Θα χρειαστεί να εφαρμόσετε όλες τις απαιτήσεις για ένα σύγχρονο αντίγραφο, καθώς και τις απαιτήσεις για το σύμπλεγμα μετρό που σχετίζεται με πρόσθετη εναλλαγή και πρόσθετη τοποθεσία (βλ. σχεδιασμός συμπλέγματος μετρό).
- Η πολυπλοκότητα της απόφασης. Ένα metrocluster είναι πολύ πιο περίπλοκο από ένα κανονικό αντίγραφο και απαιτεί πολύ περισσότερη προσοχή και προσπάθεια για τον σχεδιασμό, τη διαμόρφωση και την τεκμηρίωση.
Τελικά. Το Metrocluster είναι σίγουρα μια πολύ τεχνολογική και καλή λύση όταν χρειάζεται πραγματικά να παρέχετε RTO σε δευτερόλεπτα ή λεπτά. Αλλά εάν δεν υπάρχει τέτοιο έργο και το RTO σε ώρες είναι εντάξει για δουλειά, τότε δεν έχει νόημα να πυροβολείτε σπουργίτια από ένα κανόνι. Η συνηθισμένη αναπαραγωγή εργατών-αγροτών είναι αρκετή, αφού το σύμπλεγμα του μετρό θα προκαλέσει πρόσθετο κόστος και περιπλοκές στην υποδομή πληροφορικής.
Σχεδιασμός συστάδων μετρό
Αυτή η ενότητα δεν φιλοδοξεί να είναι ένα ολοκληρωμένο σεμινάριο σχετικά με το σχεδιασμό συμπλέγματος μετρό, αλλά δείχνει μόνο τις κύριες κατευθύνσεις που πρέπει να επεξεργαστείτε εάν αποφασίσετε να δημιουργήσετε ένα τέτοιο σύστημα. Επομένως, κατά την πραγματική υλοποίηση του συμπλέγματος του μετρό, φροντίστε να εμπλέξετε τον κατασκευαστή του συστήματος αποθήκευσης (δηλαδή εμάς) και άλλα σχετικά συστήματα για διαβούλευση.
Χώροι διεξαγωγής
Όπως αναφέρθηκε παραπάνω, ένα σύμπλεγμα μετρό απαιτεί τουλάχιστον τρεις τοποθεσίες. Δύο κέντρα δεδομένων, όπου θα λειτουργούν συστήματα αποθήκευσης και σχετικά συστήματα, καθώς και ένας τρίτος ιστότοπος, όπου θα εργάζεται ο διαιτητής.
Η συνιστώμενη απόσταση μεταξύ των κέντρων δεδομένων δεν είναι μεγαλύτερη από 40 χιλιόμετρα. Μια μεγαλύτερη απόσταση είναι πολύ πιθανό να προκαλέσει πρόσθετες καθυστερήσεις, οι οποίες είναι εξαιρετικά ανεπιθύμητες στην περίπτωση ενός συμπλέγματος μετρό. Θυμηθείτε ότι οι καθυστερήσεις θα πρέπει να είναι έως και 5 χιλιοστά του δευτερολέπτου, αν και είναι επιθυμητό να διατηρούνται εντός 2.
Οι καθυστερήσεις συνιστάται επίσης να ελέγχονται κατά τη διαδικασία σχεδιασμού. Οποιοσδήποτε πάροχος περισσότερο ή λιγότερο για ενήλικες που παρέχει ίνα μεταξύ των κέντρων δεδομένων μπορεί να οργανώσει έναν ποιοτικό έλεγχο αρκετά γρήγορα.
Όσον αφορά τις καθυστερήσεις στον διαιτητή (δηλαδή, μεταξύ της τρίτης τοποθεσίας και των δύο πρώτων), το συνιστώμενο όριο καθυστέρησης είναι έως και 200 χιλιοστά του δευτερολέπτου, δηλαδή, θα κάνει μια κανονική εταιρική σύνδεση VPN μέσω Διαδικτύου.
Εναλλαγή και δίκτυο
Σε αντίθεση με το σχήμα αναπαραγωγής, όπου αρκεί η σύνδεση συστημάτων αποθήκευσης από διαφορετικές τοποθεσίες, το σχήμα συμπλέγματος μετρό απαιτεί τη σύνδεση κεντρικών υπολογιστών και στα δύο συστήματα αποθήκευσης σε διαφορετικές τοποθεσίες. Για να γίνει πιο σαφές ποια είναι η διαφορά, και τα δύο σχήματα παρατίθενται παρακάτω.
Όπως μπορείτε να δείτε από το διάγραμμα, έχουμε κεντρικούς υπολογιστές τοποθεσίας 1 που κοιτάζουν τόσο τον αποθηκευτικό χώρο 1 όσο και τον αποθηκευτικό χώρο 2. Επίσης, αντίθετα, οι κεντρικοί υπολογιστές του ιστότοπου 2 εξετάζουν τόσο τον χώρο αποθήκευσης 2 όσο και τον χώρο αποθήκευσης 1. Δηλαδή, κάθε host βλέπει και τα δύο συστήματα αποθήκευσης. Αυτό αποτελεί προϋπόθεση για τη λειτουργία του metrocluster.
Φυσικά, δεν χρειάζεται να τραβήξετε κάθε κεντρικό υπολογιστή με ένα οπτικό καλώδιο σε άλλο κέντρο δεδομένων, δεν θα υπάρχουν αρκετές θύρες και καλώδια. Όλες αυτές οι συνδέσεις πρέπει να γίνονται μέσω διακοπτών Ethernet 10G+ ή FibreChannel 8G+ (FC μόνο για σύνδεση κεντρικών υπολογιστών και αποθήκευση για IO, το κανάλι αναπαραγωγής είναι προς το παρόν διαθέσιμο μόνο μέσω IP (Ethernet 10G+).
Τώρα λίγα λόγια για την τοπολογία του δικτύου. Ένα σημαντικό σημείο είναι η σωστή διαμόρφωση των υποδικτύων. Πρέπει να ορίσετε αμέσως πολλά υποδίκτυα για τους ακόλουθους τύπους κίνησης:
- Υποδίκτυο για αναπαραγωγή, μέσω του οποίου τα δεδομένα θα συγχρονίζονται μεταξύ των συστημάτων αποθήκευσης. Μπορεί να υπάρχουν πολλά από αυτά, σε αυτήν την περίπτωση δεν πειράζει, όλα εξαρτώνται από την τρέχουσα (ήδη υλοποιημένη) τοπολογία δικτύου. Εάν υπάρχουν δύο από αυτά, τότε, προφανώς, πρέπει να ρυθμιστεί η δρομολόγηση μεταξύ τους.
- Υποδίκτυα αποθήκευσης μέσω των οποίων οι κεντρικοί υπολογιστές θα έχουν πρόσβαση σε πόρους αποθήκευσης (αν είναι iSCSI). Θα πρέπει να υπάρχει ένα τέτοιο υποδίκτυο σε κάθε κέντρο δεδομένων.
- Έλεγχος υποδικτύων, δηλαδή τρία υποδίκτυα με δυνατότητα δρομολόγησης σε τρεις τοποθεσίες από τις οποίες γίνεται η διαχείριση της αποθήκευσης και ο διαιτητής βρίσκεται επίσης εκεί.
Δεν θεωρούμε υποδίκτυα για πρόσβαση σε πόρους κεντρικού υπολογιστή εδώ, καθώς εξαρτώνται σε μεγάλο βαθμό από εργασίες.
Ο διαχωρισμός διαφορετικής κίνησης σε διαφορετικά υποδίκτυα είναι εξαιρετικά σημαντικός (είναι ιδιαίτερα σημαντικό να διαχωρίσετε το αντίγραφο από το I/O), γιατί αν αναμίξετε όλη την κίνηση σε ένα «χοντρό» υποδίκτυο, τότε αυτή η κίνηση θα είναι αδύνατο να διαχειριστεί και σε συνθήκες δύο κέντρων δεδομένων, αυτό μπορεί να προκαλέσει ακόμα διάφορους τύπους συγκρούσεων δικτύου. Δεν θα εμβαθύνουμε σε αυτό το ζήτημα στο πλαίσιο αυτού του άρθρου, καθώς μπορείτε να διαβάσετε σχετικά με τον σχεδιασμό ενός δικτύου που εκτείνεται μεταξύ κέντρων δεδομένων στους πόρους των κατασκευαστών εξοπλισμού δικτύου, όπου αυτό περιγράφεται με μεγάλη λεπτομέρεια.
Διαμόρφωση Arbiter
Ο διαιτητής πρέπει να παρέχει πρόσβαση σε όλες τις διεπαφές ελέγχου του συστήματος αποθήκευσης μέσω πρωτοκόλλων ICMP και SSH. Θα πρέπει επίσης να σκεφτείτε την ανοχή σφαλμάτων του διαιτητή. Υπάρχει μια απόχρωση εδώ.
Το Arbiter failover είναι ιδιαίτερα επιθυμητό, αλλά δεν απαιτείται. Και τι θα συμβεί αν ο διαιτητής συντριβεί τη λάθος στιγμή;
- Η λειτουργία του metrocluster στην κανονική λειτουργία δεν θα αλλάξει, γιατί Το arbtir δεν επηρεάζει καθόλου τη λειτουργία του metrocluster σε κανονική λειτουργία (το καθήκον του είναι να αλλάζει έγκαιρα το φορτίο μεταξύ κέντρων δεδομένων)
- Ταυτόχρονα, εάν ο διαιτητής για τον έναν ή τον άλλο λόγο πέσει και «κοιμήσει» το ατύχημα στο data center, τότε δεν θα συμβεί καμία αλλαγή, γιατί δεν θα υπάρχει κανείς να δώσει τις απαραίτητες εντολές μεταγωγής και να οργανώσει απαρτία. Σε αυτήν την περίπτωση, το σύμπλεγμα του μετρό θα μετατραπεί σε ένα κανονικό σχήμα αναπαραγωγής, το οποίο θα πρέπει να αλλάξει χειροκίνητα κατά τη διάρκεια μιας καταστροφής, η οποία θα επηρεάσει το RTO.
Τι προκύπτει από αυτό; Εάν χρειάζεται πραγματικά να παρέχετε ένα ελάχιστο RTO, πρέπει να διασφαλίσετε την ανοχή σφαλμάτων του διαιτητή. Υπάρχουν δύο επιλογές για αυτό:
- Εκτελέστε μια εικονική μηχανή με έναν διαιτητή σε έναν υπερεπόπτη με ανοχή σφαλμάτων, καθώς όλοι οι ενήλικοι υπερεπόπτες υποστηρίζουν ανοχή σφαλμάτων.
- Εάν στον τρίτο ιστότοπο (σε ένα γραφείο υπό όρους) είναι πολύ τεμπέλικο να εγκαταστήσετε ένα κανονικό σύμπλεγμα και δεν υπάρχει υπάρχον σύμπλεγμα hypervisors, τότε παρέχουμε μια έκδοση υλικού του arbiter, η οποία είναι κατασκευασμένη σε κουτί 2U, στο οποίο λειτουργούν δύο συνηθισμένοι διακομιστές x-86 και η οποία μπορεί να επιβιώσει από τοπική αποτυχία.
Συνιστούμε ανεπιφύλακτα να εξασφαλίσετε την ανοχή σφαλμάτων του διαιτητή, παρά το γεγονός ότι το σύμπλεγμα του μετρό δεν το χρειάζεται σε κανονική λειτουργία. Όμως, όπως δείχνουν τόσο η θεωρία όσο και η πράξη, εάν κατασκευάσετε μια πραγματικά αξιόπιστη υποδομή ανθεκτική στις καταστροφές, τότε είναι καλύτερα να το παίξετε με ασφάλεια. Είναι καλύτερα να προστατεύσετε τον εαυτό σας και την επιχείρησή σας από τον «νόμο της κακίας», δηλαδή από την αποτυχία τόσο του διαιτητή όσο και ενός από τους χώρους όπου βρίσκεται το σύστημα αποθήκευσης.
Αρχιτεκτονική λύσης
Λαμβάνοντας υπόψη τις παραπάνω απαιτήσεις, έχουμε την ακόλουθη γενική αρχιτεκτονική λύσης.
Τα LUN θα πρέπει να κατανέμονται ομοιόμορφα στις δύο τοποθεσίες για να αποφευχθεί η έντονη συμφόρηση. Ταυτόχρονα, κατά τον προσδιορισμό μεγέθους και στα δύο κέντρα δεδομένων, είναι απαραίτητο να παρέχεται όχι μόνο διπλάσιος όγκος (που είναι απαραίτητος για την ταυτόχρονη αποθήκευση δεδομένων σε δύο συστήματα αποθήκευσης), αλλά και διπλή απόδοση σε IOPS και MB/s προκειμένου να αποφευχθεί η υποβάθμιση των εφαρμογών σε περίπτωση βλάβης ενός από τα κέντρα δεδομένων.
Ξεχωριστά, σημειώνουμε ότι με μια σωστή προσέγγιση στο μέγεθος (δηλαδή, με την προϋπόθεση ότι έχουμε προβλέψει τα κατάλληλα ανώτερα όρια IOPS και MB / s, καθώς και τους απαραίτητους πόρους CPU και RAM), εάν ένα από τα συστήματα αποθήκευσης στο σύμπλεγμα του μετρό αποτύχει, δεν θα υπάρξει σοβαρή πτώση απόδοσης σε συνθήκες προσωρινής εργασίας σε ένα σύστημα αποθήκευσης.
Αυτό εξηγείται από το γεγονός ότι σε συνθήκες ταυτόχρονης λειτουργίας δύο τοποθεσιών, η εκτέλεση της σύγχρονης αναπαραγωγής «τρώει» τη μισή απόδοση εγγραφής, καθώς κάθε συναλλαγή πρέπει να γραφτεί σε δύο συστήματα αποθήκευσης (παρόμοια με το RAID-1 / 10). Έτσι, εάν ένα από τα συστήματα αποθήκευσης αποτύχει, η επίδραση της αναπαραγωγής προσωρινά (μέχρι να ανέβει το αποτυχημένο σύστημα αποθήκευσης) εξαφανίζεται και έχουμε διπλάσια αύξηση στην απόδοση εγγραφής. Μετά την επανεκκίνηση των LUN του αποτυχημένου συστήματος αποθήκευσης στο λειτουργικό σύστημα αποθήκευσης, αυτή η διπλή αύξηση εξαφανίζεται λόγω του γεγονότος ότι υπάρχει φόρτωση από τα LUN ενός άλλου συστήματος αποθήκευσης και επιστρέφουμε στο ίδιο επίπεδο απόδοσης που είχαμε πριν από την "πτώση", αλλά μόνο στον ίδιο ιστότοπο.
Με τη βοήθεια του κατάλληλου μεγέθους, είναι δυνατό να παρασχεθούν συνθήκες υπό τις οποίες οι χρήστες δεν θα αισθανθούν καθόλου την αποτυχία ολόκληρου του συστήματος αποθήκευσης. Αλλά για άλλη μια φορά, αυτό απαιτεί πολύ προσεκτικό μέγεθος, το οποίο, παρεμπιπτόντως, μπορείτε να επικοινωνήσετε μαζί μας δωρεάν :-).
Δημιουργία συμπλέγματος μετρό
Η δημιουργία ενός συμπλέγματος μετρό μοιάζει πολύ με τη ρύθμιση της κανονικής αναπαραγωγής, την οποία περιγράψαμε . Ας επικεντρωθούμε λοιπόν στις διαφορές. Δημιουργήσαμε έναν πάγκο στο εργαστήριο με βάση την παραπάνω αρχιτεκτονική, μόνο στην ελάχιστη έκδοση: δύο συστήματα αποθήκευσης συνδεδεμένα μεταξύ τους μέσω 10G Ethernet, δύο διακόπτες 10G και ένας κεντρικός υπολογιστής που κοιτάζει μέσα από τους διακόπτες και στα δύο συστήματα αποθήκευσης με θύρες 10G. Ο διαιτητής εκτελείται σε μια εικονική μηχανή.
Κατά τη διαμόρφωση της εικονικής IP (VIP) για ένα αντίγραφο, θα πρέπει να επιλέξετε τον τύπο VIP - για ένα σύμπλεγμα μετρό.
Δημιούργησε δύο συνδέσμους αναπαραγωγής για δύο LUN και τους διένειμε σε δύο συστήματα αποθήκευσης: LUN TEST Primary σε αποθήκευση1 (σύνδεση METRO), LUN TEST2 Primary για αποθήκευση2 (σύνδεση METRO2).
Για αυτούς, διαμορφώσαμε δύο πανομοιότυπους στόχους (στην περίπτωσή μας, το iSCSI, αλλά υποστηρίζεται και το FC, η λογική διαμόρφωσης είναι η ίδια).
αποθήκευση 1:
αποθήκευση 2:
Για συνδέσμους αναπαραγωγής, έγιναν αντιστοιχίσεις σε κάθε σύστημα αποθήκευσης.
αποθήκευση 1:
αποθήκευση 2:
Ρυθμίσαμε multipath και το παρουσιάσαμε στον οικοδεσπότη.
Δημιουργία διαιτητή
Δεν χρειάζεται να κάνετε κάτι ιδιαίτερο με τον ίδιο τον διαιτητή, απλά πρέπει να τον ενεργοποιήσετε στον τρίτο ιστότοπο, να ορίσετε την IP του και να ρυθμίσετε την πρόσβαση σε αυτόν μέσω ICMP και SSH. Η ίδια η διαμόρφωση πραγματοποιείται από τα ίδια τα συστήματα αποθήκευσης. Ταυτόχρονα, αρκεί να διαμορφώσετε τον διαιτητή μία φορά σε οποιονδήποτε από τους ελεγκτές αποθήκευσης στο σύμπλεγμα μετρό, αυτές οι ρυθμίσεις θα διανεμηθούν αυτόματα σε όλους τους ελεγκτές.
Στην περιοχή Remote Replication>> Metrocluster (σε οποιονδήποτε ελεγκτή)>> κουμπί Configure.
Εισάγουμε την IP του διαιτητή, καθώς και τις διεπαφές ελέγχου των δύο ελεγκτών απομακρυσμένης αποθήκευσης.
Μετά από αυτό, πρέπει να ενεργοποιήσετε όλες τις υπηρεσίες (κουμπί "Επανεκκίνηση όλων"). Εάν κάνετε εκ νέου διαμόρφωση στο μέλλον, οι υπηρεσίες πρέπει να επανεκκινηθούν για να τεθούν σε ισχύ οι ρυθμίσεις.
Ελέγχουμε ότι όλες οι υπηρεσίες εκτελούνται.
Αυτό ολοκληρώνει τη ρύθμιση του metrocluster.
Δοκιμή σφαλμάτων
Το crash test στην περίπτωσή μας θα είναι αρκετά απλό και γρήγορο, αφού η λειτουργία αναπαραγωγής (εναλλαγή, συνέπεια κ.λπ.) εξετάστηκε στο . Επομένως, για να ελέγξουμε την αξιοπιστία του συμπλέγματος του μετρό, αρκεί να ελέγξουμε την αυτοματοποίηση ανίχνευσης ατυχήματος, μεταγωγής και απουσίας απωλειών εγγραφής (I/O stops).
Για να γίνει αυτό, προσομοιώνουμε την πλήρη αποτυχία ενός από τα συστήματα αποθήκευσης απενεργοποιώντας φυσικά και τους δύο ελεγκτές του, αφού ξεκινήσουμε την αντιγραφή ενός μεγάλου αρχείου σε ένα LUN, το οποίο θα πρέπει να ενεργοποιηθεί σε άλλο σύστημα αποθήκευσης.
Απενεργοποιήστε ένα σύστημα αποθήκευσης. Στο δεύτερο σύστημα αποθήκευσης, βλέπουμε ειδοποιήσεις και μηνύματα στα αρχεία καταγραφής ότι η σύνδεση με το γειτονικό σύστημα έχει εξαφανιστεί. Εάν διαμορφωθούν ειδοποιήσεις μέσω παρακολούθησης SMTP ή SNMP, τότε οι κατάλληλες ειδοποιήσεις θα σταλούν στον διαχειριστή.
Ακριβώς 10 δευτερόλεπτα αργότερα (βλέπεται και στα δύο στιγμιότυπα οθόνης), ο σύνδεσμος αναπαραγωγής METRO (αυτός που ήταν Κύριος στο σύστημα αποθήκευσης που πέφτει) έγινε αυτόματα Κύριος στο λειτουργικό σύστημα αποθήκευσης. Χρησιμοποιώντας την υπάρχουσα αντιστοίχιση, το LUN TEST παρέμεινε διαθέσιμο στον κεντρικό υπολογιστή, η εγγραφή έπεσε λίγο (εντός του υποσχεθέντος 10 τοις εκατό), αλλά δεν σταμάτησε.
Η δοκιμή ολοκληρώθηκε με επιτυχία.
Συνοψίζοντας
Η τρέχουσα εφαρμογή του metrocluster στα συστήματα αποθήκευσης της σειράς N AERODISK Engine σάς επιτρέπει να επιλύετε πλήρως προβλήματα όπου χρειάζεται να εξαλείψετε ή να ελαχιστοποιήσετε το χρόνο διακοπής λειτουργίας των υπηρεσιών πληροφορικής και να εξασφαλίσετε τη λειτουργία τους σε λειτουργία 24/7/365 με ελάχιστο κόστος εργασίας.
Μπορείτε να πείτε, φυσικά, ότι όλα αυτά είναι θεωρία, ιδανικές εργαστηριακές συνθήκες κ.λπ. ... ΑΛΛΑ έχουμε μια σειρά από υλοποιημένα έργα στα οποία εφαρμόσαμε τη λειτουργία αποκατάστασης από καταστροφή και τα συστήματα λειτουργούν τέλεια. Ένας από τους αρκετά γνωστούς πελάτες μας, όπου χρησιμοποιούνται μόνο δύο συστήματα αποθήκευσης σε μια διαμόρφωση ανθεκτική σε καταστροφές, έχει ήδη συμφωνήσει να δημοσιεύσει πληροφορίες σχετικά με το έργο, επομένως στο επόμενο μέρος θα μιλήσουμε για την εφαρμογή μάχης.
Ευχαριστώ, ανυπομονώ για μια παραγωγική συζήτηση.
Πηγή: www.habr.com