Γεια σας, αναγνώστες του Habr. Με αυτό το άρθρο ανοίγουμε μια σειρά που θα μιλήσει για το υπερσυγκλίνον σύστημα AERODISK vAIR που έχουμε αναπτύξει. Αρχικά, θέλαμε να πούμε τα πάντα για τα πάντα στο πρώτο άρθρο, αλλά το σύστημα είναι αρκετά περίπλοκο, οπότε θα φάμε τον ελέφαντα τμηματικά.
Ας ξεκινήσουμε την ιστορία με την ιστορία της δημιουργίας του συστήματος, ας εμβαθύνουμε στο σύστημα αρχείων ARDFS, το οποίο αποτελεί τη βάση του vAIR, και επίσης να μιλήσουμε λίγο για την τοποθέτηση αυτής της λύσης στη ρωσική αγορά.
Σε μελλοντικά άρθρα θα μιλήσουμε λεπτομερέστερα για διάφορα αρχιτεκτονικά στοιχεία (cluster, hypervisor, load balancer, σύστημα παρακολούθησης κ.λπ.), τη διαδικασία διαμόρφωσης, θέτουμε ζητήματα αδειοδότησης, παρουσιάζουμε ξεχωριστά crash tests και, φυσικά, γράψουμε για δοκιμές φορτίου και κόλλα. Θα αφιερώσουμε επίσης ένα ξεχωριστό άρθρο στην κοινοτική έκδοση του vAIR.
Είναι το Aerodisk μια ιστορία για συστήματα αποθήκευσης; Ή γιατί αρχίσαμε να κάνουμε υπερσύγκλιση εξαρχής;
Αρχικά, η ιδέα να δημιουργήσουμε τη δική μας υπερσύγκλιση μας ήρθε κάπου γύρω στο 2010. Εκείνη την εποχή, δεν υπήρχε ούτε η Aerodisk ούτε παρόμοιες λύσεις (εμπορικά υπερσυγκλίνοντα συστήματα) στην αγορά. Το καθήκον μας ήταν το εξής: από ένα σύνολο διακομιστών με τοπικούς δίσκους, ενωμένους με διασύνδεση μέσω του πρωτοκόλλου Ethernet, ήταν απαραίτητο να δημιουργήσουμε έναν εκτεταμένο χώρο αποθήκευσης και να ξεκινήσουμε εκεί εικονικές μηχανές και ένα δίκτυο λογισμικού. Όλα αυτά έπρεπε να εφαρμοστούν χωρίς συστήματα αποθήκευσης (γιατί απλά δεν υπήρχαν χρήματα για τα συστήματα αποθήκευσης και το υλικό τους και δεν είχαμε εφεύρει ακόμη τα δικά μας συστήματα αποθήκευσης).
Δοκιμάσαμε πολλές λύσεις ανοιχτού κώδικα και τελικά λύσαμε αυτό το πρόβλημα, αλλά η λύση ήταν πολύ περίπλοκη και δύσκολο να επαναληφθεί. Άλλωστε αυτή η λύση ήταν στην κατηγορία του «Δουλεύει; Μην αγγίζετε! Επομένως, έχοντας λύσει αυτό το πρόβλημα, δεν αναπτύξαμε περαιτέρω την ιδέα να μετατρέψουμε το αποτέλεσμα της δουλειάς μας σε ένα πλήρες προϊόν.
Μετά από αυτό το περιστατικό, απομακρυνθήκαμε από αυτήν την ιδέα, αλλά είχαμε ακόμα την αίσθηση ότι αυτό το πρόβλημα ήταν πλήρως επιλύσιμο και τα οφέλη μιας τέτοιας λύσης ήταν κάτι παραπάνω από προφανή. Στη συνέχεια, τα προϊόντα HCI που κυκλοφόρησαν ξένες εταιρείες επιβεβαίωσαν μόνο αυτό το συναίσθημα.
Ως εκ τούτου, στα μέσα του 2016, επιστρέψαμε σε αυτήν την εργασία ως μέρος της δημιουργίας ενός ολοκληρωμένου προϊόντος. Εκείνη την εποχή δεν είχαμε ακόμη καμία σχέση με επενδυτές, οπότε έπρεπε να αγοράσουμε ένα αναπτυξιακό περίπτερο για τα δικά μας όχι πολύ μεγάλα χρήματα. Έχοντας συλλέξει χρησιμοποιημένους διακομιστές και διακόπτες στο Avito, ξεκινήσαμε τη δουλειά.
Το κύριο αρχικό καθήκον ήταν να δημιουργήσουμε το δικό μας, αν και απλό, αλλά το δικό μας σύστημα αρχείων, το οποίο θα μπορούσε αυτόματα και ομοιόμορφα να διανέμει δεδομένα με τη μορφή εικονικών μπλοκ στον ένατο αριθμό κόμβων συμπλέγματος, που συνδέονται μέσω διασύνδεσης μέσω Ethernet. Ταυτόχρονα, το FS θα πρέπει να κλιμακώνεται καλά και εύκολα και να είναι ανεξάρτητο από γειτονικά συστήματα, δηλ. να αποξενωθεί από το vAIR με τη μορφή «απλώς μια εγκατάσταση αποθήκευσης».
Πρώτη ιδέα vAIR
Εσκεμμένα εγκαταλείψαμε τη χρήση έτοιμων λύσεων ανοιχτού κώδικα για την οργάνωση εκτεταμένης αποθήκευσης (ceph, gluster, luster και παρόμοια) προς όφελος της δικής μας ανάπτυξης, καθώς είχαμε ήδη μεγάλη εμπειρία έργου μαζί τους. Φυσικά, αυτές οι ίδιες οι λύσεις είναι εξαιρετικές και πριν εργαστούμε στο Aerodisk, υλοποιήσαμε περισσότερα από ένα έργα ολοκλήρωσης μαζί τους. Αλλά είναι άλλο πράγμα να εφαρμόζεις μια συγκεκριμένη εργασία για έναν πελάτη, να εκπαιδεύεις το προσωπικό και, ίσως, να αγοράζεις την υποστήριξη ενός μεγάλου προμηθευτή, και άλλο πράγμα να δημιουργείς ένα προϊόν που μπορεί να αναπαραχθεί εύκολα και θα χρησιμοποιηθεί για διάφορες εργασίες, τις οποίες εμείς, ως πωλητής, μπορεί ακόμη και να ξέρουμε για τον εαυτό μας δεν θα ξέρουμε. Για τον δεύτερο σκοπό, τα υπάρχοντα προϊόντα ανοιχτού κώδικα δεν ήταν κατάλληλα για εμάς, οπότε αποφασίσαμε να δημιουργήσουμε μόνοι μας ένα κατανεμημένο σύστημα αρχείων.
Δύο χρόνια αργότερα, αρκετοί προγραμματιστές (που συνδύασαν την εργασία στο vAIR με την εργασία στο κλασικό σύστημα αποθήκευσης Engine) πέτυχαν ένα συγκεκριμένο αποτέλεσμα.
Μέχρι το 2018, είχαμε γράψει ένα απλό σύστημα αρχείων και το είχαμε συμπληρώσει με το απαραίτητο υλικό. Το σύστημα συνδύασε φυσικούς (τοπικούς) δίσκους από διαφορετικούς διακομιστές σε μια επίπεδη πισίνα μέσω μιας εσωτερικής διασύνδεσης και τους «έκοψε» σε εικονικά μπλοκ, στη συνέχεια μπλοκάρει συσκευές με διαφορετικούς βαθμούς ανοχής σφαλμάτων από τα εικονικά μπλοκ, στα οποία δημιουργήθηκαν εικονικά και εκτελείται χρησιμοποιώντας τα αυτοκίνητα υπερεπόπτη KVM.
Δεν ασχοληθήκαμε πολύ με το όνομα του συστήματος αρχείων και το ονομάσαμε συνοπτικά ARDFS (μάντεψε τι σημαίνει))
Αυτό το πρωτότυπο φαινόταν καλό (όχι οπτικά, φυσικά, δεν υπήρχε ακόμα οπτικός σχεδιασμός) και έδειξε καλά αποτελέσματα όσον αφορά την απόδοση και την κλιμάκωση. Μετά το πρώτο πραγματικό αποτέλεσμα, θέσαμε αυτό το έργο σε κίνηση, οργανώνοντας ένα πλήρες περιβάλλον ανάπτυξης και μια ξεχωριστή ομάδα που ασχολήθηκε μόνο με το vAIR.
Μόλις εκείνη τη στιγμή, η γενική αρχιτεκτονική της λύσης είχε ωριμάσει, η οποία δεν έχει υποστεί ακόμη σημαντικές αλλαγές.
Κατάδυση στο σύστημα αρχείων ARDFS
Το ARDFS είναι το θεμέλιο του vAIR, το οποίο παρέχει κατανεμημένη αποθήκευση δεδομένων με ανοχή σε σφάλματα σε ολόκληρο το σύμπλεγμα. Ένα από τα (αλλά όχι τα μοναδικά) ιδιαίτερα χαρακτηριστικά του ARDFS είναι ότι δεν χρησιμοποιεί πρόσθετους αποκλειστικούς διακομιστές για μεταδεδομένα και διαχείριση. Αυτό σχεδιάστηκε αρχικά για να απλοποιήσει τη διαμόρφωση της λύσης και για την αξιοπιστία της.
Δομή αποθήκευσης
Μέσα σε όλους τους κόμβους του συμπλέγματος, το ARDFS οργανώνει μια λογική δεξαμενή από όλο τον διαθέσιμο χώρο στο δίσκο. Είναι σημαντικό να καταλάβουμε ότι ένα pool δεν είναι ακόμη δεδομένα ή μορφοποιημένος χώρος, αλλά απλώς σήμανση, δηλ. Τυχόν κόμβοι με εγκατεστημένο το vAIR, όταν προστίθενται στο σύμπλεγμα, προστίθενται αυτόματα στο κοινόχρηστο χώρο συγκέντρωσης ARDFS και οι πόροι του δίσκου γίνονται αυτόματα κοινόχρηστοι σε ολόκληρο το σύμπλεγμα (και διατίθενται για μελλοντική αποθήκευση δεδομένων). Αυτή η προσέγγιση σάς επιτρέπει να προσθέτετε και να αφαιρείτε κόμβους εν κινήσει χωρίς σοβαρές επιπτώσεις στο ήδη τρέχον σύστημα. Εκείνοι. το σύστημα είναι πολύ εύκολο να κλιμακωθεί "σε τούβλα", προσθέτοντας ή αφαιρώντας κόμβους στο σύμπλεγμα εάν είναι απαραίτητο.
Εικονικοί δίσκοι (αντικείμενα αποθήκευσης για εικονικές μηχανές) προστίθενται στο επάνω μέρος της πισίνας ARDFS, οι οποίοι είναι κατασκευασμένοι από εικονικά μπλοκ μεγέθους 4 megabyte. Οι εικονικοί δίσκοι αποθηκεύουν απευθείας δεδομένα. Το σχήμα ανοχής σφαλμάτων ρυθμίζεται επίσης σε επίπεδο εικονικού δίσκου.
Όπως ίσως έχετε ήδη μαντέψει, για την ανοχή σφαλμάτων του υποσυστήματος δίσκου, δεν χρησιμοποιούμε την έννοια του RAID (Redundant array ofdependent Disks), αλλά χρησιμοποιούμε RAIN (Redundant array ofdependent Nodes). Εκείνοι. Η ανοχή σφαλμάτων μετριέται, αυτοματοποιείται και διαχειρίζεται με βάση τους κόμβους και όχι τους δίσκους. Οι δίσκοι, φυσικά, είναι επίσης ένα αντικείμενο αποθήκευσης, παρακολουθούνται, όπως όλα τα άλλα, μπορείτε να εκτελέσετε όλες τις τυπικές λειτουργίες μαζί τους, συμπεριλαμβανομένης της συναρμολόγησης ενός τοπικού RAID υλικού, αλλά το σύμπλεγμα λειτουργεί ειδικά σε κόμβους.
Σε μια κατάσταση όπου θέλετε πραγματικά RAID (για παράδειγμα, ένα σενάριο που υποστηρίζει πολλαπλές αποτυχίες σε μικρά συμπλέγματα), τίποτα δεν σας εμποδίζει να χρησιμοποιήσετε τοπικούς ελεγκτές RAID και να δημιουργήσετε εκτεταμένο χώρο αποθήκευσης και μια αρχιτεκτονική RAIN από πάνω. Αυτό το σενάριο είναι αρκετά ζωντανό και υποστηρίζεται από εμάς, γι' αυτό θα μιλήσουμε σε ένα άρθρο σχετικά με τυπικά σενάρια χρήσης vAIR.
Σχέδια ανοχής σφαλμάτων αποθήκευσης
Μπορεί να υπάρχουν δύο σχήματα ανοχής σφαλμάτων για εικονικούς δίσκους στο vAIR:
1) Συντελεστής αναπαραγωγής ή απλώς αντιγραφή - αυτή η μέθοδος ανοχής σφαλμάτων είναι τόσο απλή όσο ένα ραβδί και ένα σχοινί. Η σύγχρονη αναπαραγωγή εκτελείται μεταξύ κόμβων με συντελεστή 2 (2 αντίγραφα ανά σύμπλεγμα) ή 3 (3 αντίγραφα, αντίστοιχα). Το RF-2 επιτρέπει σε έναν εικονικό δίσκο να αντέξει την αποτυχία ενός κόμβου στο σύμπλεγμα, αλλά «τρώει» το μισό του χρήσιμου όγκου και το RF-3 θα αντέξει την αποτυχία 2 κόμβων στο σύμπλεγμα, αλλά διατηρεί τα 2/3 του χρήσιμος όγκος για τις ανάγκες του. Αυτό το σχήμα είναι πολύ παρόμοιο με το RAID-1, δηλαδή, ένας εικονικός δίσκος που έχει διαμορφωθεί σε RF-2 είναι ανθεκτικός στην αποτυχία οποιουδήποτε κόμβου στο σύμπλεγμα. Σε αυτή την περίπτωση, όλα θα πάνε καλά με τα δεδομένα και ακόμη και το I/O δεν θα σταματήσει. Όταν ο πεσμένος κόμβος επιστρέψει στην υπηρεσία, θα ξεκινήσει η αυτόματη ανάκτηση/συγχρονισμός δεδομένων.
Ακολουθούν παραδείγματα κατανομής δεδομένων RF-2 και RF-3 σε κανονική λειτουργία και σε κατάσταση αστοχίας.
Έχουμε μια εικονική μηχανή χωρητικότητας 8MB μοναδικών (χρήσιμων) δεδομένων, η οποία λειτουργεί σε 4 κόμβους vAIR. Είναι σαφές ότι στην πραγματικότητα είναι απίθανο να υπάρχει τόσο μικρός όγκος, αλλά για ένα σχήμα που αντανακλά τη λογική της λειτουργίας ARDFS, αυτό το παράδειγμα είναι το πιο κατανοητό. Τα AB είναι εικονικά μπλοκ 4 MB που περιέχουν μοναδικά δεδομένα εικονικής μηχανής. Το RF-2 δημιουργεί δύο αντίγραφα αυτών των μπλοκ A1+A2 και B1+B2, αντίστοιχα. Αυτά τα μπλοκ «στρώνονται» μεταξύ των κόμβων, αποφεύγοντας τη διασταύρωση των ίδιων δεδομένων στον ίδιο κόμβο, δηλαδή, το αντίγραφο Α1 δεν θα βρίσκεται στον ίδιο κόμβο με το αντίγραφο Α2. Το ίδιο με το Β1 και το Β2.
Εάν ένας από τους κόμβους αποτύχει (για παράδειγμα, ο κόμβος Νο. 3, ο οποίος περιέχει ένα αντίγραφο του B1), αυτό το αντίγραφο ενεργοποιείται αυτόματα στον κόμβο όπου δεν υπάρχει αντίγραφο του αντιγράφου του (δηλαδή αντίγραφο του B2).
Έτσι, ο εικονικός δίσκος (και το VM, αντίστοιχα) μπορεί εύκολα να επιβιώσει από την αποτυχία ενός κόμβου στο σχήμα RF-2.
Το σχήμα αναπαραγωγής, αν και απλό και αξιόπιστο, αντιμετωπίζει το ίδιο πρόβλημα με το RAID1 - δεν υπάρχει αρκετός χρησιμοποιήσιμος χώρος.
2) Η κωδικοποίηση διαγραφής ή η κωδικοποίηση διαγραφής (γνωστή και ως "πλεονάζουσα κωδικοποίηση", "κωδικοποίηση διαγραφής" ή "κωδικός πλεονασμού") υπάρχει για την επίλυση του παραπάνω προβλήματος. Το EC είναι ένα σύστημα πλεονασμού που παρέχει υψηλή διαθεσιμότητα δεδομένων με μικρότερο επιβάρυνση χώρου στο δίσκο σε σύγκριση με την αναπαραγωγή. Η αρχή λειτουργίας αυτού του μηχανισμού είναι παρόμοια με το RAID 5, 6, 6P.
Κατά την κωδικοποίηση, η διαδικασία EC διαιρεί ένα εικονικό μπλοκ (4 MB από προεπιλογή) σε πολλά μικρότερα "κομμάτια δεδομένων" ανάλογα με το σχήμα EC (για παράδειγμα, ένα σχήμα 2+1 διαιρεί κάθε μπλοκ 4 MB σε 2 κομμάτια των 2 MB). Στη συνέχεια, αυτή η διαδικασία δημιουργεί "κομμάτια ισοτιμίας" για τα "κομμάτια δεδομένων" που δεν είναι μεγαλύτερα από ένα από τα προηγουμένως διαχωρισμένα μέρη. Κατά την αποκωδικοποίηση, το EC δημιουργεί τα κομμάτια που λείπουν διαβάζοντας τα «επιζώντα» δεδομένα σε ολόκληρο το σύμπλεγμα.
Για παράδειγμα, ένας εικονικός δίσκος με σχήμα 2 + 1 EC, που υλοποιείται σε 4 κόμβους συμπλέγματος, θα αντέξει εύκολα την αποτυχία ενός κόμβου στο σύμπλεγμα με τον ίδιο τρόπο όπως ο RF-2. Σε αυτήν την περίπτωση, τα γενικά έξοδα θα είναι χαμηλότερα, συγκεκριμένα, ο συντελεστής ωφέλιμης χωρητικότητας για το RF-2 είναι 2 και για το EC 2+1 θα είναι 1,5.
Για να το περιγράψουμε πιο απλά, η ουσία είναι ότι το εικονικό μπλοκ χωρίζεται σε 2-8 (γιατί από 2 έως 8, βλέπε παρακάτω) "κομμάτια", και για αυτά τα κομμάτια υπολογίζονται "κομμάτια" ισοτιμίας παρόμοιου όγκου.
Ως αποτέλεσμα, τα δεδομένα και η ισοτιμία κατανέμονται ομοιόμορφα σε όλους τους κόμβους του συμπλέγματος. Ταυτόχρονα, όπως και με την αναπαραγωγή, το ARDFS διανέμει αυτόματα δεδομένα μεταξύ των κόμβων με τέτοιο τρόπο ώστε να αποτρέπεται η αποθήκευση πανομοιότυπων δεδομένων (αντίγραφα δεδομένων και η ισοτιμία τους) στον ίδιο κόμβο, προκειμένου να εξαλειφθεί η πιθανότητα απώλειας δεδομένων λόγω στο γεγονός ότι τα δεδομένα και η ισοτιμία τους θα καταλήξουν ξαφνικά σε έναν κόμβο αποθήκευσης που αποτυγχάνει.
Παρακάτω είναι ένα παράδειγμα, με την ίδια εικονική μηχανή 8 MB και 4 κόμβους, αλλά με ένα σχήμα EC 2+1.
Τα μπλοκ Α και Β χωρίζονται σε δύο κομμάτια των 2 MB το καθένα (δύο επειδή 2+1), δηλαδή Α1+Α2 και Β1+Β2. Σε αντίθεση με ένα αντίγραφο, το Α1 δεν είναι αντίγραφο του Α2, είναι ένα εικονικό μπλοκ Α, χωρισμένο σε δύο μέρη, το ίδιο και με το μπλοκ Β. Συνολικά, παίρνουμε δύο σετ των 4 MB, καθένα από τα οποία περιέχει δύο κομμάτια των δύο MB. Στη συνέχεια, για καθένα από αυτά τα σύνολα, η ισοτιμία υπολογίζεται με όγκο όχι περισσότερο από ένα τεμάχιο (δηλαδή 2 MB), λαμβάνουμε επιπλέον + 2 τεμάχια ισοτιμίας (AP και BP). Συνολικά έχουμε δεδομένα 4×2 + ισοτιμία 2×2.
Στη συνέχεια, τα κομμάτια "στρώνονται" μεταξύ των κόμβων, έτσι ώστε τα δεδομένα να μην τέμνονται με την ισοτιμία τους. Εκείνοι. Οι A1 και A2 δεν θα βρίσκονται στον ίδιο κόμβο με το AP.
Σε περίπτωση αποτυχίας ενός κόμβου (για παράδειγμα, και του τρίτου), το πεσμένο μπλοκ Β1 θα αποκατασταθεί αυτόματα από την ισοτιμία BP, η οποία είναι αποθηκευμένη στον κόμβο Νο. 2, και θα ενεργοποιηθεί στον κόμβο όπου υπάρχει χωρίς ισοτιμία Β, δηλ. κομμάτι BP. Σε αυτό το παράδειγμα, αυτός είναι ο κόμβος Νο. 1
Είμαι βέβαιος ότι ο αναγνώστης έχει μια ερώτηση:
"Όλα όσα περιγράψατε έχουν εφαρμοστεί εδώ και καιρό τόσο από ανταγωνιστές όσο και σε λύσεις ανοιχτού κώδικα, ποια είναι η διαφορά μεταξύ της εφαρμογής του EC στο ARDFS;"
Και τότε θα υπάρξουν ενδιαφέροντα χαρακτηριστικά του ARDFS.
Κωδικοποίηση διαγραφής με έμφαση στην ευελιξία
Αρχικά, παρείχαμε ένα αρκετά ευέλικτο σχήμα EC X+Y, όπου το X είναι ίσο με έναν αριθμό από το 2 έως το 8 και το Y είναι ίσο με έναν αριθμό από το 1 έως το 8, αλλά πάντα μικρότερο ή ίσο με το X. Αυτό το σχήμα παρέχεται για ευελιξία. Η αύξηση του αριθμού των τεμαχίων δεδομένων (X) στα οποία χωρίζεται το εικονικό μπλοκ επιτρέπει τη μείωση των γενικών εξόδων, δηλαδή την αύξηση του χρησιμοποιήσιμου χώρου.
Η αύξηση του αριθμού των τμημάτων ισοτιμίας (Y) αυξάνει την αξιοπιστία του εικονικού δίσκου. Όσο μεγαλύτερη είναι η τιμή Y, τόσο περισσότεροι κόμβοι στο σύμπλεγμα μπορεί να αποτύχουν. Φυσικά, η αύξηση του όγκου ισοτιμίας μειώνει την ποσότητα της χρησιμοποιήσιμης χωρητικότητας, αλλά αυτό είναι ένα τίμημα για την αξιοπιστία.
Η εξάρτηση της απόδοσης από τα κυκλώματα EC είναι σχεδόν άμεση: όσο περισσότερα «κομμάτια», τόσο χαμηλότερη είναι η απόδοση· εδώ, φυσικά, χρειάζεται μια ισορροπημένη άποψη.
Αυτή η προσέγγιση επιτρέπει στους διαχειριστές να διαμορφώνουν τον εκτεταμένο χώρο αποθήκευσης με μέγιστη ευελιξία. Μέσα στο ARDFS pool, μπορείτε να χρησιμοποιήσετε οποιαδήποτε σχήματα ανοχής σφαλμάτων και τους συνδυασμούς τους, κάτι που, κατά τη γνώμη μας, είναι επίσης πολύ χρήσιμο.
Παρακάτω είναι ένας πίνακας που συγκρίνει πολλά (όχι όλα τα πιθανά) σχήματα RF και EC.
Ο πίνακας δείχνει ότι ακόμη και ο πιο «ψαγμένος» συνδυασμός EC 8+7, ο οποίος επιτρέπει την απώλεια έως και 7 κόμβων σε ένα σύμπλεγμα ταυτόχρονα, «τρώει» λιγότερο χρησιμοποιήσιμο χώρο (1,875 έναντι 2) από την τυπική αναπαραγωγή και προστατεύει 7 φορές καλύτερα , γεγονός που καθιστά αυτόν τον μηχανισμό προστασίας, αν και πιο περίπλοκο, πολύ πιο ελκυστικό σε καταστάσεις όπου είναι απαραίτητο να διασφαλιστεί η μέγιστη αξιοπιστία σε συνθήκες περιορισμένου χώρου στο δίσκο. Ταυτόχρονα, πρέπει να καταλάβετε ότι κάθε «συν» σε X ή Y θα είναι ένα επιπλέον κόστος απόδοσης, επομένως στο τρίγωνο μεταξύ αξιοπιστίας, εξοικονόμησης και απόδοσης πρέπει να επιλέξετε πολύ προσεκτικά. Για το λόγο αυτό, θα αφιερώσουμε ένα ξεχωριστό άρθρο για τη διαγραφή μεγέθους κωδικοποίησης.
Αξιοπιστία και αυτονομία του συστήματος αρχείων
Το ARDFS εκτελείται τοπικά σε όλους τους κόμβους του συμπλέγματος και τους συγχρονίζει χρησιμοποιώντας τα δικά του μέσα μέσω αποκλειστικών διεπαφών Ethernet. Το σημαντικό σημείο είναι ότι το ARDFS συγχρονίζει ανεξάρτητα όχι μόνο τα δεδομένα, αλλά και τα μεταδεδομένα που σχετίζονται με την αποθήκευση. Ενώ εργαζόμασταν στο ARDFS, μελετήσαμε ταυτόχρονα μια σειρά από υπάρχουσες λύσεις και ανακαλύψαμε ότι πολλές συγχρονίζουν το meta του συστήματος αρχείων χρησιμοποιώντας ένα εξωτερικό κατανεμημένο DBMS, το οποίο χρησιμοποιούμε επίσης για συγχρονισμό, αλλά μόνο διαμορφώσεις, όχι μεταδεδομένα FS (σχετικά με αυτό και άλλα σχετικά υποσυστήματα στο επόμενο άρθρο).
Ο συγχρονισμός των μεταδεδομένων FS χρησιμοποιώντας ένα εξωτερικό DBMS είναι, φυσικά, μια λειτουργική λύση, αλλά τότε η συνέπεια των δεδομένων που είναι αποθηκευμένα στο ARDFS θα εξαρτηθεί από το εξωτερικό DBMS και τη συμπεριφορά του (και, ειλικρινά, είναι μια ιδιότροπη κυρία), η οποία σε η γνώμη μας είναι κακή. Γιατί; Εάν τα μεταδεδομένα του FS καταστραφούν, τα ίδια τα δεδομένα του FS μπορούν επίσης να ειπωθούν «αντίο», οπότε αποφασίσαμε να ακολουθήσουμε μια πιο περίπλοκη αλλά αξιόπιστη διαδρομή.
Κατασκευάσαμε μόνοι μας το υποσύστημα συγχρονισμού μεταδεδομένων για το ARDFS και ζει εντελώς ανεξάρτητα από γειτονικά υποσυστήματα. Εκείνοι. κανένα άλλο υποσύστημα δεν μπορεί να καταστρέψει τα δεδομένα ARDFS. Κατά τη γνώμη μας, αυτός είναι ο πιο αξιόπιστος και σωστός τρόπος, αλλά ο χρόνος θα δείξει αν αυτό είναι πράγματι έτσι. Επιπλέον, υπάρχει ένα επιπλέον πλεονέκτημα με αυτή την προσέγγιση. Το ARDFS μπορεί να χρησιμοποιηθεί ανεξάρτητα από το vAIR, όπως και η τεντωμένη αποθήκευση, την οποία σίγουρα θα χρησιμοποιήσουμε σε μελλοντικά προϊόντα.
Ως αποτέλεσμα, με την ανάπτυξη του ARDFS, λάβαμε ένα ευέλικτο και αξιόπιστο σύστημα αρχείων που δίνει την επιλογή όπου μπορείτε να εξοικονομήσετε χωρητικότητα ή να εγκαταλείψετε τα πάντα στην απόδοση ή να κάνετε εξαιρετικά αξιόπιστη αποθήκευση με λογικό κόστος, αλλά μειώνοντας τις απαιτήσεις απόδοσης.
Μαζί με μια απλή πολιτική αδειοδότησης και ένα ευέλικτο μοντέλο παράδοσης (κοιτάζοντας μπροστά, το vAIR αδειοδοτείται από κόμβο και παραδίδεται είτε ως λογισμικό είτε ως πακέτο λογισμικού), αυτό σας επιτρέπει να προσαρμόσετε με μεγάλη ακρίβεια τη λύση σε μια μεγάλη ποικιλία απαιτήσεων πελατών και τότε διατηρείται εύκολα αυτή η ισορροπία.
Ποιος χρειάζεται αυτό το θαύμα;
Από τη μία, μπορούμε να πούμε ότι υπάρχουν ήδη παίκτες στην αγορά που έχουν σοβαρές λύσεις στον τομέα της υπερσύγκλισης και προς τα εκεί οδεύουμε ουσιαστικά. Φαίνεται ότι αυτή η δήλωση είναι αλήθεια, ΑΛΛΑ...
Από την άλλη, όταν βγαίνουμε στα χωράφια και επικοινωνούμε με πελάτες, εμείς και οι συνεργάτες μας βλέπουμε ότι αυτό δεν ισχύει καθόλου. Υπάρχουν πολλές εργασίες για την υπερσύγκλιση, σε ορισμένα μέρη οι άνθρωποι απλώς δεν γνώριζαν ότι υπήρχαν τέτοιες λύσεις, σε άλλα φαινόταν ακριβό, σε άλλα υπήρξαν ανεπιτυχείς δοκιμές εναλλακτικών λύσεων και σε άλλα απαγορεύουν καθόλου την αγορά λόγω κυρώσεων. Σε γενικές γραμμές, το χωράφι αποδείχθηκε ότι δεν ήταν οργωμένο, οπότε πήγαμε να σηκώσουμε παρθένο χώμα))).
Πότε το σύστημα αποθήκευσης είναι καλύτερο από το GCS;
Καθώς συνεργαζόμαστε με την αγορά, μας ρωτούν συχνά πότε είναι καλύτερο να χρησιμοποιούμε ένα κλασικό σχήμα με συστήματα αποθήκευσης και πότε να χρησιμοποιούμε υπερσυγκλίνοντα; Πολλές εταιρείες που παράγουν GCS (ειδικά εκείνες που δεν διαθέτουν συστήματα αποθήκευσης στο χαρτοφυλάκιό τους) λένε: «Τα συστήματα αποθήκευσης γίνονται απαρχαιωμένα, μόνο υπερσυγκλίνοντα!» Αυτή είναι μια τολμηρή δήλωση, αλλά δεν αντικατοπτρίζει πλήρως την πραγματικότητα.
Στην πραγματικότητα, η αγορά αποθήκευσης κινείται όντως προς την υπερσύγκλιση και παρόμοιες λύσεις, αλλά πάντα υπάρχει ένα «αλλά».
Πρώτον, τα κέντρα δεδομένων και οι υποδομές πληροφορικής που κατασκευάζονται σύμφωνα με το κλασικό σχήμα με συστήματα αποθήκευσης δεν μπορούν να ανακατασκευαστούν εύκολα, επομένως ο εκσυγχρονισμός και η ολοκλήρωση τέτοιων υποδομών παραμένει κληρονομιά για 5-7 χρόνια.
Δεύτερον, η υποδομή που κατασκευάζεται αυτή τη στιγμή στο μεγαλύτερο μέρος της (εννοεί τη Ρωσική Ομοσπονδία) έχει κατασκευαστεί σύμφωνα με το κλασικό σχήμα χρησιμοποιώντας συστήματα αποθήκευσης, και όχι επειδή οι άνθρωποι δεν γνωρίζουν για την υπερσύγκλιση, αλλά επειδή η αγορά υπερσύγκλισης είναι νέα, λύσεις και τα πρότυπα δεν έχουν ακόμη καθιερωθεί, οι άνθρωποι της πληροφορικής δεν έχουν ακόμη εκπαιδευτεί, έχουν μικρή εμπειρία, αλλά πρέπει να δημιουργήσουν κέντρα δεδομένων εδώ και τώρα. Και αυτή η τάση θα διαρκέσει για άλλα 3-5 χρόνια (και μετά μια άλλη κληρονομιά, βλέπε σημείο 1).
Τρίτον, υπάρχει ένας καθαρά τεχνικός περιορισμός σε πρόσθετες μικρές καθυστερήσεις 2 χιλιοστών του δευτερολέπτου ανά εγγραφή (εξαιρουμένης της τοπικής κρυφής μνήμης, φυσικά), που είναι το κόστος της κατανεμημένης αποθήκευσης.
Λοιπόν, ας μην ξεχνάμε τη χρήση μεγάλων φυσικών διακομιστών που αγαπούν την κατακόρυφη κλιμάκωση του υποσυστήματος του δίσκου.
Υπάρχουν πολλές απαραίτητες και δημοφιλείς εργασίες όπου τα συστήματα αποθήκευσης συμπεριφέρονται καλύτερα από το GCS. Εδώ, φυσικά, όσοι κατασκευαστές δεν έχουν συστήματα αποθήκευσης στο χαρτοφυλάκιο προϊόντων τους δεν θα συμφωνήσουν μαζί μας, αλλά είμαστε έτοιμοι να διαφωνήσουμε εύλογα. Φυσικά, εμείς, ως προγραμματιστές και των δύο προϊόντων, σίγουρα θα συγκρίνουμε συστήματα αποθήκευσης και GCS σε μία από τις μελλοντικές μας δημοσιεύσεις, όπου θα δείξουμε ξεκάθαρα ποιο είναι καλύτερο υπό ποιες συνθήκες.
Και πού θα λειτουργούν καλύτερα οι υπερσυγκλίνουσες λύσεις από τα συστήματα αποθήκευσης;
Με βάση τα παραπάνω σημεία, μπορούν να εξαχθούν τρία προφανή συμπεράσματα:
- Όπου επιπλέον 2 χιλιοστά του δευτερολέπτου λανθάνοντος χρόνου για εγγραφή, που εμφανίζεται σταθερά σε οποιοδήποτε προϊόν (τώρα δεν μιλάμε για συνθετικά, τα νανοδευτερόλεπτα μπορούν να εμφανιστούν στα συνθετικά), είναι μη κρίσιμο, το υπερσύγκλινο είναι κατάλληλο.
- Όπου το φορτίο από μεγάλους φυσικούς διακομιστές μπορεί να μετατραπεί σε πολλούς μικρούς εικονικούς και να κατανεμηθεί μεταξύ των κόμβων, η υπερσύγκλιση θα λειτουργήσει επίσης καλά εκεί.
- Όπου η οριζόντια κλιμάκωση είναι μεγαλύτερη προτεραιότητα από την κατακόρυφη κλίμακα, το GCS θα τα πάει πολύ καλά και εκεί.
Ποιες είναι αυτές οι λύσεις;
- Όλες οι τυπικές υπηρεσίες υποδομής (υπηρεσία καταλόγου, αλληλογραφία, EDMS, διακομιστές αρχείων, μικρά ή μεσαία συστήματα ERP και BI κ.λπ.). Αυτό το ονομάζουμε «γενικό υπολογισμό».
- Η υποδομή των παρόχων cloud, όπου είναι απαραίτητη η γρήγορη και τυποποιημένη οριζόντια επέκταση και η εύκολη «κοπή» μεγάλου αριθμού εικονικών μηχανών για πελάτες.
- Υποδομή εικονικής επιφάνειας εργασίας (VDI), όπου εκτελούνται πολλές μικρές εικονικές μηχανές χρηστών και «επιπλέουν» αθόρυβα σε ένα ομοιόμορφο σύμπλεγμα.
- Δίκτυα υποκαταστημάτων, όπου κάθε υποκατάστημα χρειάζεται μια τυπική, ανεκτική σε σφάλματα, αλλά φθηνή υποδομή 15-20 εικονικών μηχανών.
- Οποιοσδήποτε κατανεμημένος υπολογισμός (υπηρεσίες μεγάλων δεδομένων, για παράδειγμα). Όπου το φορτίο δεν πηγαίνει «σε βάθος», αλλά «σε πλάτος».
- Δοκιμαστικά περιβάλλοντα όπου είναι αποδεκτές πρόσθετες μικρές καθυστερήσεις, αλλά υπάρχουν περιορισμοί προϋπολογισμού, επειδή πρόκειται για δοκιμές.
Αυτή τη στιγμή, για αυτές τις εργασίες έχουμε κάνει το AERODISK vAIR και σε αυτές εστιάζουμε (με επιτυχία μέχρι στιγμής). Ίσως αυτό αλλάξει σύντομα, γιατί... ο κόσμος δεν μένει ακίνητος.
Ετσι…
Αυτό ολοκληρώνει το πρώτο μέρος μιας μεγάλης σειράς άρθρων· στο επόμενο άρθρο θα μιλήσουμε για την αρχιτεκτονική της λύσης και τα συστατικά που χρησιμοποιούνται.
Καλωσορίζουμε ερωτήσεις, προτάσεις και εποικοδομητικές διαφωνίες.
Πηγή: www.habr.com