Αποθηκευτικός χώρος στο Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor

Αποθηκευτικός χώρος στο Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor

Εκσυγχρονίζω!. Στα σχόλια, ένας από τους αναγνώστες πρότεινε να δοκιμάσετε Λίνστορ (ίσως το δουλεύει ο ίδιος) γι' αυτό πρόσθεσα μια ενότητα σχετικά με αυτήν τη λύση. έγραψα κι εγώ δημοσιεύστε πώς να το εγκαταστήσετε, γιατί η διαδικασία είναι πολύ διαφορετική από τις υπόλοιπες.

Για να είμαι ειλικρινής, τα παράτησα και τα παράτησα Kubernetes (τουλάχιστον για τώρα). θα χρησιμοποιήσω Heroku. Γιατί; Λόγω αποθήκευσης! Ποιος θα το φανταζόταν ότι θα ασχολούμουν περισσότερο με την αποθήκευση παρά με την ίδια την Kubernetes. χρησιμοποιώ Σύννεφο Hetznerεπειδή είναι φθηνό και η απόδοση είναι καλή και από την αρχή έχω αναπτύξει συμπλέγματα χρησιμοποιώντας κτηματίας. Δεν δοκίμασα τις διαχειριζόμενες υπηρεσίες Kubernetes από το Google/Amazon/Microsoft/DigitalOcean, κ.λπ., κ.λπ., γιατί ήθελα να μάθω τα πάντα μόνος μου. Είμαι και λιτός.

Οπότε, ναι, πέρασα πολύ χρόνο προσπαθώντας να αποφασίσω ποιον αποθηκευτικό χώρο να επιλέξω όταν αξιολογούσα μια πιθανή στοίβα Kubernetes. Προτιμώ λύσεις ανοιχτού κώδικα, όχι μόνο λόγω της τιμής, αλλά εξέτασα μερικές επιλογές επί πληρωμή από περιέργεια επειδή έχουν δωρεάν εκδόσεις με περιορισμούς. Σημείωσα μερικούς αριθμούς από πρόσφατες δοκιμές όταν συνέκρινα διαφορετικές επιλογές και μπορεί να ενδιαφέρουν όσους μαθαίνουν για τον χώρο αποθήκευσης Kubernetes. Αν και προσωπικά έχω αποχαιρετήσει την Kubernetes προς το παρόν. Θέλω επίσης να αναφέρω Πρόγραμμα οδήγησης CSI, το οποίο μπορεί να παρέχει απευθείας τόμους Hetzner Cloud, αλλά δεν το έχω δοκιμάσει ακόμα. Εξέτασα τον αποθηκευτικό χώρο που καθορίζεται από το λογισμικό cloud, επειδή χρειαζόμουν αναπαραγωγή και τη δυνατότητα γρήγορης προσάρτησης επίμονων τόμων σε οποιονδήποτε κόμβο, ειδικά σε περίπτωση αποτυχίας κόμβου και άλλων παρόμοιων καταστάσεων. Ορισμένες λύσεις προσφέρουν στιγμιότυπα σε χρόνο και αντίγραφα ασφαλείας εκτός τοποθεσίας, κάτι που είναι βολικό.

Δοκίμασα 6-7 λύσεις αποθήκευσης:

OpenEBS

Όπως είπα ήδη σε προηγούμενη ανάρτησηΈχοντας δοκιμάσει τις περισσότερες από τις επιλογές από τη λίστα, στάθηκα αρχικά στο OpenEBS. Το OpenEBS είναι πολύ εύκολο στην εγκατάσταση και τη χρήση, αλλά για να είμαι ειλικρινής, μετά από δοκιμή με πραγματικά δεδομένα υπό φόρτωση, απογοητεύτηκα με την απόδοσή του. Αυτό είναι ανοιχτού κώδικα και οι προγραμματιστές είναι μόνοι τους Χαλαρό κανάλι πάντα πολύ εξυπηρετικός όταν χρειαζόμουν βοήθεια. Δυστυχώς, έχει πολύ κακή απόδοση σε σύγκριση με άλλες επιλογές, επομένως οι δοκιμές έπρεπε να επαναληφθούν. Το OpenEBS διαθέτει αυτήν τη στιγμή 3 μηχανές αποθήκευσης, αλλά δημοσιεύω αποτελέσματα συγκριτικής αξιολόγησης για το cStor. Δεν έχω ακόμη αριθμούς για το Jiva και το LocalPV.

Με λίγα λόγια, το Jiva είναι λίγο πιο γρήγορο και το LocalPV είναι γενικά γρήγορο, όχι χειρότερο από το σημείο αναφοράς του δίσκου άμεσα. Το πρόβλημα με το LocalPV είναι ότι η πρόσβαση στον τόμο είναι δυνατή μόνο στον κόμβο όπου προετοιμάστηκε και δεν υπάρχει καθόλου αναπαραγωγή. Αντιμετώπισα κάποια προβλήματα κατά την επαναφορά ενός αντιγράφου ασφαλείας μέσω Velero σε ένα νέο σύμπλεγμα επειδή τα ονόματα των κόμβων ήταν διαφορετικά. Αν μιλάμε για αντίγραφα ασφαλείας, το cStor έχει πρόσθετο για το Velero, με το οποίο μπορείτε να δημιουργήσετε αντίγραφα ασφαλείας στιγμιότυπων εκτός τοποθεσίας σε μια χρονική στιγμή, κάτι που είναι πιο βολικό από τα αντίγραφα ασφαλείας σε επίπεδο αρχείου με το Velero-Restic. έγραψα πολλά σενάρια, για να διευκολύνετε τη διαχείριση αντιγράφων ασφαλείας και επαναφοράς με αυτήν την προσθήκη. Συνολικά, μου αρέσει πολύ το OpenEBS, αλλά η απόδοσή του...

Κορώνη

Το Rook είναι επίσης ανοιχτού κώδικα και διαφέρει από τις υπόλοιπες επιλογές της λίστας στο ότι είναι ένας ενορχηστρωτής αποθήκευσης που εκτελεί πολύπλοκες εργασίες διαχείρισης αποθήκευσης με διαφορετικά backend, π.χ. Κεφ, EdgeFS και άλλα, γεγονός που απλοποιεί πολύ τη δουλειά. Είχα προβλήματα με το EfgeFS όταν το δοκίμασα πριν λίγους μήνες, οπότε δοκίμασα κυρίως με τον Ceph. Το Ceph όχι μόνο προσφέρει αποθήκευση μπλοκ, αλλά και αποθήκευση αντικειμένων συμβατή με S3/Swift και σύστημα κατανεμημένων αρχείων. Αυτό που μου αρέσει στο Ceph είναι η δυνατότητα να διασπείρονται δεδομένα όγκου σε πολλούς δίσκους, έτσι ώστε ο τόμος να μπορεί να χρησιμοποιεί περισσότερο χώρο στο δίσκο από αυτόν που χωράει σε έναν μόνο δίσκο. Είναι άνετο. Ένα άλλο ωραίο χαρακτηριστικό είναι ότι όταν προσθέτετε δίσκους σε ένα σύμπλεγμα, αναδιανέμει αυτόματα δεδομένα σε όλους τους δίσκους.

Ο Ceph έχει στιγμιότυπα, αλλά από όσο ξέρω, δεν μπορούν να χρησιμοποιηθούν απευθείας στο Rook/Kubernetes. Είναι αλήθεια ότι δεν μπήκα βαθιά σε αυτό. Αλλά δεν υπάρχουν αντίγραφα ασφαλείας εκτός τοποθεσίας, επομένως θα πρέπει να χρησιμοποιήσετε κάτι με το Velero/Restic, αλλά υπάρχουν μόνο αντίγραφα ασφαλείας σε επίπεδο αρχείου, όχι στιγμιότυπα σημείου-σε-χρόνου. Αυτό που μου άρεσε πολύ στον Rook ήταν το πόσο εύκολο είναι να δουλεύεις με τον Ceph - κρύβει σχεδόν όλα τα περίπλοκα πράγματα και προσφέρει εργαλεία για να μιλήσεις απευθείας με τον Ceph για αντιμετώπιση προβλημάτων. Δυστυχώς, κατά τη διάρκεια του stress test των τόμων Ceph, συνέχισα να αντιμετωπίζω προβλήματα αυτό το πρόβλημα, που κάνει τον Ceph να γίνει ασταθής. Δεν είναι ακόμη σαφές εάν πρόκειται για ένα σφάλμα στον ίδιο τον Ceph ή ένα πρόβλημα στον τρόπο με τον οποίο ο Rook διαχειρίζεται τον Ceph. Πήρα τις ρυθμίσεις της μνήμης και βελτιώθηκε, αλλά το πρόβλημα δεν λύθηκε πλήρως. Ο Ceph έχει αξιοπρεπείς επιδόσεις, όπως μπορείτε να δείτε στα παρακάτω σημεία αναφοράς. Έχει και καλό ταμπλό.

Rancher Longhorn

Μου αρέσει πολύ το Longhorn. Κατά τη γνώμη μου, αυτή είναι μια πολλά υποσχόμενη λύση. Είναι αλήθεια ότι οι ίδιοι οι προγραμματιστές (Rancher Labs) παραδέχονται ότι δεν είναι ακόμη κατάλληλο για το εργασιακό περιβάλλον, και αυτό φαίνεται. Είναι ανοιχτού κώδικα και έχει αξιοπρεπή απόδοση (αν και δεν το έχουν βελτιστοποιήσει ακόμα), αλλά οι τόμοι χρειάζονται πολύ χρόνο για να συνδεθούν στο pod και στη χειρότερη περίπτωση χρειάζονται 15-16 λεπτά, ειδικά μετά την επαναφορά ενός μεγάλου αντιγράφου ασφαλείας ή αναβάθμιση του φόρτου εργασίας. Έχει στιγμιότυπα και αντίγραφα ασφαλείας εκτός τοποθεσίας αυτών των στιγμιότυπων, αλλά ισχύουν μόνο για τόμους, επομένως θα χρειαστείτε κάτι σαν το Velero για να δημιουργήσετε αντίγραφα ασφαλείας άλλων πόρων. Τα αντίγραφα ασφαλείας και οι επαναφορές είναι πολύ αξιόπιστα, αλλά απρεπώς αργά. Σοβαρά, απλά απίστευτα αργό. Η χρήση της CPU και το φόρτο του συστήματος συχνά αυξάνονται όταν εργάζεστε με μεσαία ποσότητα δεδομένων στο Longhorn. Υπάρχει ένα βολικό ταμπλό για τη διαχείριση του Longhorn. Έχω ήδη πει ότι μου αρέσει το Longhorn, αλλά θέλει λίγη δουλειά.

StorageOS

Το StorageOS είναι το πρώτο προϊόν επί πληρωμή στη λίστα. Έχει μια έκδοση προγραμματιστή με περιορισμένο μέγεθος διαχειριζόμενης αποθήκευσης 500 GB, αλλά δεν νομίζω ότι υπάρχει όριο στον αριθμό των κόμβων. Το τμήμα πωλήσεων μου είπε ότι το κόστος ξεκινά από 125 $ το μήνα για 1 TB, αν θυμάμαι καλά. Υπάρχει ένας βασικός πίνακας οργάνων και ένα βολικό CLI, αλλά κάτι περίεργο συμβαίνει με την απόδοση: σε ορισμένα σημεία αναφοράς είναι αρκετά αξιοπρεπές, αλλά στο stress test όγκου δεν μου άρεσε καθόλου η ταχύτητα. Γενικά, δεν ξέρω τι να πω. Οπότε δεν κατάλαβα πολλά. Δεν υπάρχουν αντίγραφα ασφαλείας εκτός τοποθεσίας εδώ και θα πρέπει επίσης να χρησιμοποιήσετε το Velero με το Restic για τη δημιουργία αντιγράφων ασφαλείας τόμων. Είναι περίεργο, γιατί το προϊόν πληρώνεται. Και οι προγραμματιστές δεν ήταν πρόθυμοι να επικοινωνήσουν στο Slack.

κοκκινολαίμης

Έμαθα για τον Robin στο Reddit από τον τεχνικό τους διευθυντή. Δεν τον είχα ξανακούσει ποτέ. Ίσως επειδή έψαχνα για δωρεάν λύσεις, αλλά ο Robin πληρώνεται. Έχουν μια αρκετά γενναιόδωρη δωρεάν έκδοση με 10 TB αποθήκευσης και τρεις κόμβους. Συνολικά, το προϊόν είναι αρκετά αξιοπρεπές και έχει ωραία χαρακτηριστικά. Υπάρχει ένα υπέροχο CLI, αλλά το πιο ωραίο είναι ότι μπορείτε να κάνετε λήψη στιγμιότυπου και να δημιουργήσετε αντίγραφα ασφαλείας ολόκληρης της εφαρμογής (στον επιλογέα πόρων αυτό ονομάζεται Helm releases ή "flex apps"), συμπεριλαμβανομένων τόμων και άλλων πόρων, ώστε να μπορείτε να κάνετε χωρίς το Velero. Και όλα θα ήταν υπέροχα αν όχι για μια μικρή λεπτομέρεια: αν επαναφέρετε (ή «εισάγετε», όπως λέγεται στο Robin) μια εφαρμογή σε ένα νέο σύμπλεγμα - για παράδειγμα, σε περίπτωση ανάκαμψης από μια καταστροφή - την αποκατάσταση, φυσικά, λειτουργεί, αλλά συνεχίστε να δημιουργείτε αντίγραφα ασφαλείας της εφαρμογής απαγορεύεται. Αυτό απλά δεν είναι δυνατό σε αυτήν την έκδοση, όπως επιβεβαίωσαν οι προγραμματιστές. Αυτό είναι, για να το θέσω ήπια, περίεργο, ειδικά λαμβάνοντας υπόψη τα άλλα πλεονεκτήματα (για παράδειγμα, απίστευτα γρήγορα αντίγραφα ασφαλείας και επαναφορά). Οι προγραμματιστές υπόσχονται να διορθώσουν τα πάντα μέχρι την επόμενη έκδοση. Η απόδοση είναι γενικά καλή, αλλά παρατήρησα ένα περίεργο: αν εκτελώ το σημείο αναφοράς απευθείας σε έναν τόμο που είναι συνδεδεμένος στον κεντρικό υπολογιστή, η ταχύτητα ανάγνωσης είναι πολύ μεγαλύτερη από την εκτέλεση του ίδιου τόμου μέσα από το pod. Όλα τα άλλα αποτελέσματα είναι πανομοιότυπα, αλλά θεωρητικά δεν πρέπει να υπάρχει διαφορά. Παρόλο που εργάζονται πάνω σε αυτό, ήμουν αναστατωμένος για το πρόβλημα με την επαναφορά και τη δημιουργία αντιγράφων ασφαλείας - νόμιζα ότι είχα βρει επιτέλους μια κατάλληλη λύση και ήμουν ακόμη διατεθειμένος να πληρώσω για αυτήν όταν χρειαζόμουν περισσότερο χώρο ή περισσότερους διακομιστές.

portworx

Δεν έχω πολλά να πω εδώ. Αυτό είναι ένα προϊόν επί πληρωμή, εξίσου δροσερό και ακριβό. Η απόδοση είναι απλά καταπληκτική. Αυτός είναι ο καλύτερος δείκτης μέχρι στιγμής. Ο Slack μου είπε ότι η τιμολόγηση ξεκινά από 205 $ ανά μήνα ανά κόμβο, όπως αναφέρεται στο GKE Marketplace της Google. Δεν ξέρω αν θα είναι φθηνότερο αν αγοράσεις απευθείας. Δεν μπορώ να το αντέξω οικονομικά ούτως ή άλλως, γι' αυτό απογοητεύτηκα πολύ, πολύ που η άδεια προγραμματιστή (έως 1 TB και 3 κόμβοι) είναι πρακτικά άχρηστη με το Kubernetes, εκτός αν είστε ικανοποιημένοι με τη στατική παροχή. Ήλπιζα ότι η άδεια τόμου θα υποβαθμιζόταν αυτόματα σε προγραμματιστή στο τέλος της δοκιμαστικής περιόδου, αλλά αυτό δεν συνέβη. Η άδεια προγραμματιστή μπορεί να χρησιμοποιηθεί απευθείας μόνο με το Docker και η διαμόρφωση στο Kubernetes είναι πολύ δυσκίνητη και περιορισμένη. Προτιμώ βέβαια το ανοιχτό κώδικα, αλλά αν είχα τα χρήματα θα επέλεγα σίγουρα το Portworx. Μέχρι στιγμής, η απόδοσή του απλά δεν συγκρίνεται με άλλες επιλογές.

Λίνστορ

Πρόσθεσα αυτήν την ενότητα μετά τη δημοσίευση της ανάρτησης, όταν ένας αναγνώστης πρότεινε να δοκιμάσει το Linstor. Το δοκίμασα και μου άρεσε! Χρειάζεται όμως ακόμα να σκάψουμε βαθύτερα. Τώρα μπορώ να πω ότι η απόδοση δεν είναι κακή (πρόσθεσα τα αποτελέσματα αναφοράς παρακάτω). Ουσιαστικά, πήρα την ίδια απόδοση με τον δίσκο κατευθείαν, χωρίς καμία επιβάρυνση. (Μην ρωτάτε γιατί το Portworx έχει καλύτερα νούμερα από το σημείο αναφοράς του δίσκου απευθείας. Δεν έχω ιδέα. Magic, υποθέτω.) Οπότε το Linstor φαίνεται πολύ αποτελεσματικό μέχρι στιγμής. Δεν είναι τόσο δύσκολο να εγκατασταθεί, αλλά δεν είναι τόσο εύκολο όσο άλλες επιλογές. Πρώτα έπρεπε να εγκαταστήσω το Linstor (μονάδα πυρήνα και εργαλεία/υπηρεσίες) και να διαμορφώσω το LVM για λεπτή παροχή και υποστήριξη στιγμιότυπων εκτός Kubernetes, απευθείας στον κεντρικό υπολογιστή και, στη συνέχεια, να δημιουργήσω τους πόρους που απαιτούνται για τη χρήση αποθηκευτικού χώρου από το Kubernetes. Δεν μου άρεσε που δεν λειτουργούσε στο CentOS και έπρεπε να χρησιμοποιήσω το Ubuntu. Όχι τρομερό, φυσικά, αλλά λίγο ενοχλητικό, γιατί η τεκμηρίωση (που είναι εξαιρετική, παρεμπιπτόντως) αναφέρει αρκετά πακέτα που δεν μπορούν να βρεθούν στα καθορισμένα αποθετήρια Epel. Το Linstor έχει στιγμιότυπα, αλλά όχι αντίγραφα ασφαλείας εκτός τοποθεσίας, οπότε και εδώ έπρεπε να χρησιμοποιήσω το Velero με το Restic για τη δημιουργία αντιγράφων ασφαλείας τόμων. Θα προτιμούσα στιγμιότυπα αντί για αντίγραφα ασφαλείας σε επίπεδο αρχείου, αλλά αυτό μπορεί να γίνει ανεκτό εάν η λύση είναι αποδοτική και αξιόπιστη. Το Linstor είναι ανοιχτού κώδικα, αλλά έχει πληρωμένη υποστήριξη. Αν καταλαβαίνω καλά, μπορεί να χρησιμοποιηθεί χωρίς περιορισμούς, ακόμα και αν δεν έχετε συμβόλαιο υποστήριξης, αλλά αυτό πρέπει να διευκρινιστεί. Δεν ξέρω πόσο ελεγμένο είναι το Linstor για το Kubernetes, αλλά το ίδιο το επίπεδο αποθήκευσης είναι εκτός του Kubernetes και, προφανώς, η λύση δεν εμφανίστηκε χθες, επομένως πιθανότατα έχει ήδη δοκιμαστεί σε πραγματικές συνθήκες. Υπάρχει κάποια λύση εδώ που θα με κάνει να αλλάξω γνώμη και να επιστρέψω στο Kubernetes; Δεν ξέρω. Πρέπει ακόμα να σκάψουμε βαθύτερα και να μελετήσουμε την αναπαραγωγή. Ας δούμε. Αλλά η πρώτη εντύπωση είναι καλή. Σίγουρα θα προτιμούσα να χρησιμοποιήσω τα δικά μου συμπλέγματα Kubernetes αντί για Heroku για να έχω περισσότερη ελευθερία και να μάθω νέα πράγματα. Δεδομένου ότι το Linstor δεν είναι τόσο εύκολο στην εγκατάσταση όσο άλλοι, θα γράψω μια ανάρτηση σχετικά σύντομα.

Σημεία αναφοράς

Δυστυχώς, δεν κράτησα πολλές σημειώσεις για τη σύγκριση γιατί δεν πίστευα ότι θα έγραφα γι' αυτό. Έχω αποτελέσματα μόνο από τα βασικά σημεία αναφοράς fio και μόνο για συμπλέγματα μεμονωμένων κόμβων, επομένως δεν έχω ακόμη αριθμούς για επαναλαμβανόμενες διαμορφώσεις. Αλλά από αυτά τα αποτελέσματα μπορείτε να πάρετε μια γενική ιδέα για το τι να περιμένετε από κάθε επιλογή, επειδή τα συνέκρινα στους ίδιους διακομιστές cloud, 4 πυρήνες, 16 GB μνήμης RAM, με επιπλέον δίσκο 100 GB για τους δοκιμασμένους τόμους. Έτρεξα τα σημεία αναφοράς τρεις φορές για κάθε λύση και υπολόγισα το μέσο αποτέλεσμα, καθώς και επαναφορά των ρυθμίσεων διακομιστή για κάθε προϊόν. Όλα αυτά είναι εντελώς αντιεπιστημονικά, για να σας δώσω μια γενική ιδέα. Σε άλλες δοκιμές, αντέγραψα 38 GB φωτογραφιών και βίντεο από τον τόμο για να δοκιμάσω την ανάγνωση και τη γραφή, αλλά, δυστυχώς, δεν έσωσα τους αριθμούς. Εν ολίγοις: Το Portworkx ήταν πολύ πιο γρήγορο.

Για τη συγκριτική αξιολόγηση όγκου χρησιμοποίησα αυτό το μανιφέστο:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: dbench
spec:
  storageClassName: ...
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: batch/v1
kind: Job
metadata:
  name: dbench
spec:
  template:
    spec:
      containers:
      - name: dbench
        image: sotoaster/dbench:latest
        imagePullPolicy: IfNotPresent
        env:
          - name: DBENCH_MOUNTPOINT
            value: /data
          - name: FIO_SIZE
            value: 1G
        volumeMounts:
        - name: dbench-pv
          mountPath: /data
      restartPolicy: Never
      volumes:
      - name: dbench-pv
        persistentVolumeClaim:
          claimName: dbench
  backoffLimit: 4

Πρώτα δημιούργησα έναν τόμο με την κατάλληλη κατηγορία αποθήκευσης και μετά έτρεξα τη δουλειά με το fio στα παρασκήνια. Πήρα 1 GB για να υπολογίσω την απόδοση και να μην περιμένω πολύ. Εδώ είναι τα αποτελέσματα:

Αποθηκευτικός χώρος στο Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor

Έχω επισημάνει την καλύτερη τιμή για κάθε μέτρηση με πράσινο και τη χειρότερη με κόκκινο.

Συμπέρασμα

Όπως μπορείτε να δείτε, στις περισσότερες περιπτώσεις το Portworx είχε καλύτερη απόδοση από άλλες. Αλλά για μένα είναι ακριβό. Δεν ξέρω πόσο κοστίζει ο Robin, αλλά έχουν μια εξαιρετική δωρεάν έκδοση, οπότε αν θέλετε ένα προϊόν επί πληρωμή, μπορείτε να το δοκιμάσετε (ελπίζουμε να διορθώσουν το πρόβλημα με την επαναφορά και τα αντίγραφα ασφαλείας σύντομα). Από τα τρία δωρεάν, είχα τα λιγότερα προβλήματα με το OpenEBS, αλλά η απόδοσή του είναι αβυσσαλέα. Κρίμα που δεν έσωσα περισσότερα αποτελέσματα, αλλά ελπίζω οι αριθμοί και τα σχόλιά μου να σας βοηθήσουν.

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο