ProHoster > Blog > διαχείριση > Συμβουλές και κόλπα για τη συνεργασία με τον Ceph σε πολυάσχολα έργα

Συμβουλές και κόλπα για τη συνεργασία με τον Ceph σε πολυάσχολα έργα

Συμβουλές και κόλπα για τη συνεργασία με τον Ceph σε πολυάσχολα έργα

Χρησιμοποιώντας το Ceph ως χώρο αποθήκευσης δικτύου σε έργα με διαφορετικό φορτίο, μπορεί να συναντήσουμε διάφορες εργασίες που με την πρώτη ματιά δεν φαίνονται απλές ή ασήμαντες. Για παράδειγμα:

  • μετεγκατάσταση δεδομένων από το παλιό Ceph στο νέο με μερική χρήση προηγούμενων διακομιστών στο νέο σύμπλεγμα.
  • λύση στο πρόβλημα της κατανομής χώρου στο δίσκο στο Ceph.

Αντιμετωπίζοντας τέτοια προβλήματα, βρισκόμαστε αντιμέτωποι με την ανάγκη να αφαιρέσουμε σωστά το OSD χωρίς απώλεια δεδομένων, κάτι που είναι ιδιαίτερα σημαντικό όταν αντιμετωπίζουμε μεγάλες ποσότητες δεδομένων. Αυτό θα συζητηθεί στο άρθρο.

Οι μέθοδοι που περιγράφονται παρακάτω είναι σχετικές για οποιαδήποτε έκδοση του Ceph. Επιπλέον, θα ληφθεί υπόψη το γεγονός ότι ο Ceph μπορεί να αποθηκεύσει μεγάλο όγκο δεδομένων: για να αποφευχθεί η απώλεια δεδομένων και άλλα προβλήματα, ορισμένες ενέργειες θα «χωριστούν» σε αρκετές άλλες.

Πρόλογος για την OSD

Δεδομένου ότι δύο από τις τρεις συνταγές που συζητήθηκαν είναι αφιερωμένες στην OSD (Δαίμονας αποθήκευσης αντικειμένων), πριν βουτήξετε στο πρακτικό μέρος - εν συντομία για το τι είναι στο Ceph και γιατί είναι τόσο σημαντικό.

Πρώτα απ 'όλα, πρέπει να πούμε ότι ολόκληρο το σύμπλεγμα Ceph αποτελείται από πολλά OSD. Όσο περισσότερα είναι, τόσο μεγαλύτερος είναι ο όγκος δωρεάν δεδομένων στο Ceph. Είναι εύκολο να το καταλάβεις από εδώ κύρια λειτουργία OSD: Αποθηκεύει δεδομένα αντικειμένων Ceph στα συστήματα αρχείων όλων των κόμβων συμπλέγματος και παρέχει πρόσβαση δικτύου σε αυτά (για ανάγνωση, εγγραφή και άλλα αιτήματα).

Στο ίδιο επίπεδο, οι παράμετροι αναπαραγωγής ορίζονται με αντιγραφή αντικειμένων μεταξύ διαφορετικών OSD. Και εδώ μπορείτε να αντιμετωπίσετε διάφορα προβλήματα, οι λύσεις των οποίων θα συζητηθούν παρακάτω.

Υπόθεση Νο 1. Καταργήστε με ασφάλεια το OSD από το σύμπλεγμα Ceph χωρίς απώλεια δεδομένων

Η ανάγκη κατάργησης του OSD μπορεί να προκληθεί από την κατάργηση του διακομιστή από το σύμπλεγμα - για παράδειγμα, για την αντικατάστασή του με άλλο διακομιστή - κάτι που συνέβη σε εμάς, με αποτέλεσμα τη συγγραφή αυτού του άρθρου. Έτσι, ο απώτερος στόχος της χειραγώγησης είναι να εξαχθούν όλα τα OSD και τα mons σε έναν δεδομένο διακομιστή, ώστε να μπορεί να διακοπεί.

Για ευκολία και για να αποφύγουμε μια κατάσταση όπου, κατά την εκτέλεση εντολών, κάνουμε λάθος υποδεικνύοντας το απαιτούμενο OSD, θα ορίσουμε μια ξεχωριστή μεταβλητή, η τιμή της οποίας θα είναι ο αριθμός του OSD που θα διαγραφεί. Ας την φωνάξουμε ${ID} — εδώ και κάτω, μια τέτοια μεταβλητή αντικαθιστά τον αριθμό του OSD με το οποίο εργαζόμαστε.

Ας δούμε την κατάσταση πριν ξεκινήσουμε την εργασία:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME      STATUS REWEIGHT PRI-AFF
-1       0.46857 root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
 1   ssd 0.15619      osd.1     up     1.00000  1.00000
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2     up     1.00000  1.00000

Για να ξεκινήσετε την αφαίρεση του OSD, θα πρέπει να εκτελέσετε ομαλά reweight σε αυτό στο μηδέν. Με αυτόν τον τρόπο μειώνουμε τον όγκο των δεδομένων στο OSD εξισορροπώντας το με άλλα OSD. Για να το κάνετε αυτό, εκτελέστε τις ακόλουθες εντολές:

ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78

... και ούτω καθεξής μέχρι το μηδέν.

Απαιτείται ομαλή εξισορρόπησηγια να μην χαθούν δεδομένα. Αυτό ισχύει ιδιαίτερα εάν το OSD περιέχει μεγάλο όγκο δεδομένων. Για να βεβαιωθείτε ότι μετά την εκτέλεση των εντολών reweight όλα πήγαν καλά, μπορείς να το ολοκληρώσεις ceph -s ή σε ένα ξεχωριστό παράθυρο τερματικού εκτελέστε ceph -w προκειμένου να παρατηρήσετε τις αλλαγές σε πραγματικό χρόνο.

Όταν το OSD "αδειάσει", μπορείτε να προχωρήσετε στην τυπική λειτουργία για να το αφαιρέσετε. Για να το κάνετε αυτό, μεταφέρετε το επιθυμητό OSD στην κατάσταση down:

ceph osd down osd.${ID}

Ας «βγάλουμε» το OSD από το σύμπλεγμα:

ceph osd out osd.${ID}

Ας σταματήσουμε την υπηρεσία OSD και ας αποπροσαρτήσουμε το διαμέρισμα της στο FS:

systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}

Αφαιρέστε το OSD από Χάρτης CRUSH:

ceph osd crush remove osd.${ID}

Ας διαγράψουμε τον χρήστη OSD:

ceph auth del osd.${ID}

Και τέλος, ας αφαιρέσουμε το ίδιο το OSD:

ceph osd rm osd.${ID}

Σημείωση: Εάν χρησιμοποιείτε έκδοση Ceph Luminous ή μεταγενέστερη, τότε τα παραπάνω βήματα αφαίρεσης OSD μπορούν να μειωθούν σε δύο εντολές:

ceph osd out osd.${ID}
ceph osd purge osd.${ID}

Εάν, αφού ολοκληρώσετε τα βήματα που περιγράφονται παραπάνω, εκτελέσετε την εντολή ceph osd tree, τότε θα πρέπει να είναι σαφές ότι στον διακομιστή όπου εκτελέστηκε η εργασία δεν υπάρχουν πλέον OSD για τις οποίες πραγματοποιήθηκαν οι παραπάνω λειτουργίες:

root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT  TYPE NAME     STATUS REWEIGHT PRI-AFF
-1       0.46857      root default
-3       0.15619      host hv-1
-5       0.15619      host hv-2
-7       0.15619      host hv-3
 2   ssd 0.15619      osd.2    up     1.00000  1.00000

Στην πορεία, σημειώστε ότι η κατάσταση του συμπλέγματος Ceph θα πάει HEALTH_WARN, και θα δούμε επίσης μείωση του αριθμού των OSD και του διαθέσιμου χώρου στο δίσκο.

Τα παρακάτω θα περιγράψουν τα βήματα που θα απαιτηθούν εάν θέλετε να διακόψετε εντελώς τον διακομιστή και, κατά συνέπεια, να τον αφαιρέσετε από τον Ceph. Σε αυτή την περίπτωση, είναι σημαντικό να το θυμάστε αυτό Πριν τερματίσετε τη λειτουργία του διακομιστή, πρέπει να αφαιρέσετε όλα τα OSD σε αυτόν τον διακομιστή.

Εάν δεν έχουν απομείνει άλλα OSD σε αυτόν τον διακομιστή, τότε αφού τα αφαιρέσετε θα πρέπει να εξαιρέσετε τον διακομιστή από τον χάρτη OSD hv-2εκτελώντας την ακόλουθη εντολή:

ceph osd crush rm hv-2

Διαγράφω mon από τον διακομιστή hv-2εκτελώντας την παρακάτω εντολή σε άλλο διακομιστή (δηλαδή σε αυτήν την περίπτωση, σε hv-1):

ceph-deploy mon destroy hv-2

Μετά από αυτό, μπορείτε να σταματήσετε τον διακομιστή και να ξεκινήσετε τις επόμενες ενέργειες (εκ νέου ανάπτυξή του, κ.λπ.).

Υπόθεση Νο 2. Κατανομή χώρου στο δίσκο σε ένα ήδη δημιουργημένο σύμπλεγμα Ceph

Θα ξεκινήσω τη δεύτερη ιστορία με έναν πρόλογο για το PG (Ομάδες Τοποθέτησης). Ο κύριος ρόλος του PG στο Ceph είναι κυρίως να συγκεντρώνει αντικείμενα Ceph και να τα αναπαράγει περαιτέρω στο OSD. Ο τύπος με τον οποίο μπορείτε να υπολογίσετε την απαιτούμενη ποσότητα PG είναι μέσα σχετική ενότητα Τεκμηρίωση Κεφ. Αυτό το θέμα συζητείται και εκεί με συγκεκριμένα παραδείγματα.

Έτσι: ένα από τα κοινά προβλήματα κατά τη χρήση του Ceph είναι ο μη ισορροπημένος αριθμός OSD και PG μεταξύ των πισινών στο Ceph.

Πρώτον, εξαιτίας αυτού, μπορεί να προκύψει μια κατάσταση όταν καθορίζονται πάρα πολλά PG σε ένα μικρό pool, κάτι που είναι ουσιαστικά μια παράλογη χρήση του χώρου στο δίσκο στο σύμπλεγμα. Δεύτερον, στην πράξη υπάρχει ένα πιο σοβαρό πρόβλημα: υπερχείλιση δεδομένων σε ένα από τα OSD. Αυτό συνεπάγεται τη μετάβαση του συμπλέγματος πρώτα στην κατάσταση HEALTH_WARN, και μετά HEALTH_ERR. Ο λόγος για αυτό είναι ότι ο Ceph, κατά τον υπολογισμό του διαθέσιμου όγκου δεδομένων (μπορείτε να το μάθετε από MAX AVAIL στην έξοδο εντολών ceph df για κάθε ομάδα χωριστά) βασίζεται στον όγκο των διαθέσιμων δεδομένων στο OSD. Εάν δεν υπάρχει αρκετός χώρος σε τουλάχιστον ένα OSD, δεν μπορούν να εγγραφούν περισσότερα δεδομένα έως ότου τα δεδομένα κατανεμηθούν σωστά σε όλα τα OSD.

Αξίζει να διευκρινιστεί ότι αυτά τα προβλήματα αποφασίζονται σε μεγάλο βαθμό στο στάδιο διαμόρφωσης του συμπλέγματος Ceph. Ένα από τα εργαλεία που μπορείτε να χρησιμοποιήσετε είναι Ceph PGCalc. Με τη βοήθειά του, υπολογίζεται σαφώς η απαιτούμενη ποσότητα PG. Ωστόσο, μπορείτε επίσης να καταφύγετε σε αυτό σε μια κατάσταση όπου το σύμπλεγμα Ceph ήδη έχει ρυθμιστεί εσφαλμένα. Αξίζει εδώ να διευκρινιστεί ότι ως μέρος της επιδιόρθωσης πιθανότατα θα χρειαστεί να μειώσετε τον αριθμό των PG και αυτή η δυνατότητα δεν είναι διαθέσιμη σε παλαιότερες εκδόσεις του Ceph (εμφανίστηκε μόνο στην έκδοση Ναυτίλος).

Ας φανταστούμε λοιπόν την ακόλουθη εικόνα: το σύμπλεγμα έχει μια κατάσταση HEALTH_WARN λόγω εξάντλησης χώρου σε ένα από τα OSD. Αυτό θα υποδεικνύεται από ένα σφάλμα HEALTH_WARN: 1 near full osd. Παρακάτω είναι ένας αλγόριθμος για την έξοδο από αυτήν την κατάσταση.

Πρώτα απ 'όλα, πρέπει να διανείμετε τα διαθέσιμα δεδομένα μεταξύ των υπόλοιπων OSD. Έχουμε ήδη πραγματοποιήσει μια παρόμοια λειτουργία στην πρώτη περίπτωση, όταν «στραγγίσαμε» τον κόμβο - με τη μόνη διαφορά ότι τώρα θα χρειαστεί να μειώσουμε ελαφρώς reweight. Για παράδειγμα, έως 0.95:

ceph osd reweight osd.${ID} 0.95

Αυτό ελευθερώνει χώρο στο δίσκο στο OSD και διορθώνει το σφάλμα στην υγεία του ceph. Ωστόσο, όπως ήδη αναφέρθηκε, αυτό το πρόβλημα παρουσιάζεται κυρίως λόγω εσφαλμένης διαμόρφωσης του Ceph στα αρχικά στάδια: είναι πολύ σημαντικό να κάνετε μια αναδιάρθρωση ώστε να μην εμφανίζεται στο μέλλον.

Στη συγκεκριμένη περίπτωσή μας, όλα κατέληξαν στο εξής:

  • τιμή πολύ υψηλή replication_count σε μια από τις πισίνες,
  • πάρα πολύ PG σε μια πισίνα και πολύ λίγο σε μια άλλη.

Ας χρησιμοποιήσουμε την ήδη αναφερθείσα αριθμομηχανή. Δείχνει ξεκάθαρα τι πρέπει να εισαχθεί και, καταρχήν, δεν υπάρχει τίποτα περίπλοκο. Έχοντας ορίσει τις απαραίτητες παραμέτρους, λαμβάνουμε τις ακόλουθες συστάσεις:

Σημείωση: Εάν ρυθμίζετε ένα σύμπλεγμα Ceph από την αρχή, μια άλλη χρήσιμη λειτουργία της αριθμομηχανής είναι η δημιουργία εντολών που θα δημιουργήσουν ομάδες από την αρχή με τις παραμέτρους που καθορίζονται στον πίνακα.

Η τελευταία στήλη σάς βοηθά να πλοηγηθείτε - Προτεινόμενος αριθμός PG. Στην περίπτωσή μας, χρήσιμο είναι και το δεύτερο, όπου υποδεικνύεται η παράμετρος αναπαραγωγής, αφού αποφασίσαμε να αλλάξουμε τον πολλαπλασιαστή αναπαραγωγής.

Επομένως, πρώτα πρέπει να αλλάξετε τις παραμέτρους αναπαραγωγής - αυτό αξίζει να το κάνετε πρώτα, καθώς μειώνοντας τον πολλαπλασιαστή, θα ελευθερώσουμε χώρο στο δίσκο. Καθώς εκτελείται η εντολή, θα παρατηρήσετε ότι ο διαθέσιμος χώρος στο δίσκο θα αυξηθεί:

ceph osd pool $pool_name set $replication_size

Και μετά την ολοκλήρωσή του αλλάζουμε τις τιμές των παραμέτρων pg_num и pgp_num ως εξής:

ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_number

Είναι σημαντικό: πρέπει να αλλάξουμε τον αριθμό των PG διαδοχικά σε κάθε ομάδα και να μην αλλάξουμε τις τιμές σε άλλες ομάδες μέχρι να εξαφανιστούν οι προειδοποιήσεις "Υποβαθμισμένος πλεονασμός δεδομένων" и "n-αριθμός pgs υποβαθμισμένο".

Μπορείτε επίσης να ελέγξετε ότι όλα πήγαν καλά χρησιμοποιώντας τις εξόδους εντολών ceph health detail и ceph -s.

Υπόθεση Νο. 3. Μεταφορά μιας εικονικής μηχανής από το LVM στο Ceph RBD

Σε μια κατάσταση όπου ένα έργο χρησιμοποιεί εικονικές μηχανές εγκατεστημένες σε ενοικιασμένους διακομιστές γυμνού μετάλλου, συχνά προκύπτει το ζήτημα της αποθήκευσης με ανοχή σε σφάλματα. Είναι επίσης πολύ επιθυμητό να υπάρχει αρκετός χώρος σε αυτόν τον χώρο αποθήκευσης... Μια άλλη συνηθισμένη κατάσταση: υπάρχει μια εικονική μηχανή με τοπική αποθήκευση στον διακομιστή και πρέπει να επεκτείνετε το δίσκο, αλλά δεν υπάρχει πουθενά να πάτε, επειδή δεν υπάρχει ελεύθερος χώρος στο δίσκο που απομένει στον διακομιστή.

Το πρόβλημα μπορεί να λυθεί με διάφορους τρόπους - για παράδειγμα, με μετεγκατάσταση σε άλλο διακομιστή (εάν υπάρχει) ή προσθέτοντας νέους δίσκους στον διακομιστή. Αλλά δεν είναι πάντα δυνατό να γίνει αυτό, επομένως η μετάβαση από το LVM στο Ceph μπορεί να είναι μια εξαιρετική λύση σε αυτό το πρόβλημα. Επιλέγοντας αυτήν την επιλογή, απλοποιούμε επίσης την περαιτέρω διαδικασία μετεγκατάστασης μεταξύ διακομιστών, καθώς δεν θα υπάρχει ανάγκη μετακίνησης τοπικού χώρου αποθήκευσης από τον έναν υπερεπόπτη στον άλλο. Το μόνο πρόβλημα είναι ότι θα πρέπει να σταματήσετε το VM ενώ εκτελούνται οι εργασίες.

Η παρακάτω συνταγή προέρχεται από άρθρο από αυτό το blog, οι οδηγίες του οποίου έχουν δοκιμαστεί στην πράξη. Παρεμπιπτόντως, Η μέθοδος της απρόσκοπτης μετανάστευσης περιγράφεται επίσης εκεί, ωστόσο, στην περίπτωσή μας απλά δεν χρειαζόταν, οπότε δεν το ελέγξαμε. Εάν αυτό είναι κρίσιμο για το έργο σας, θα χαρούμε να ακούσουμε για τα αποτελέσματα στα σχόλια.

Ας περάσουμε στο πρακτικό κομμάτι. Στο παράδειγμα χρησιμοποιούμε virsh και, κατά συνέπεια, libvirt. Πρώτα, βεβαιωθείτε ότι το Ceph pool στο οποίο θα μετεγκατασταθούν τα δεδομένα είναι συνδεδεμένο στο libvirt:

virsh pool-dumpxml $ceph_pool

Η περιγραφή της πισίνας πρέπει να περιέχει δεδομένα σύνδεσης στο Ceph με δεδομένα εξουσιοδότησης.

Το επόμενο βήμα είναι ότι η εικόνα LVM μετατρέπεται σε Ceph RBD. Ο χρόνος εκτέλεσης εξαρτάται κυρίως από το μέγεθος της εικόνας:

qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_name

Μετά τη μετατροπή, θα παραμείνει μια εικόνα LVM, η οποία θα είναι χρήσιμη εάν αποτύχει η μετεγκατάσταση του VM στο RBD και πρέπει να επαναφέρετε τις αλλαγές. Επίσης, για να μπορούμε να επαναφέρουμε γρήγορα τις αλλαγές, ας δημιουργήσουμε ένα αντίγραφο ασφαλείας του αρχείου διαμόρφωσης εικονικής μηχανής:

virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml

... και επεξεργαστείτε το πρωτότυπο (vm_name.xml). Ας βρούμε ένα μπλοκ με μια περιγραφή του δίσκου (ξεκινά με τη γραμμή <disk type='file' device='disk'> και τελειώνει με </disk>) και μειώστε το στην ακόλουθη μορφή:

<disk type='network' device='disk'>
<driver name='qemu'/>
<auth username='libvirt'>
  <secret type='ceph' uuid='sec-ret-uu-id'/>
 </auth>
<source protocol='rbd' name='$ceph_pool/$vm_image_name>
  <host name='10.0.0.1' port='6789'/>
  <host name='10.0.0.2' port='6789'/>
</source>
<target dev='vda' bus='virtio'/> 
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>

Ας δούμε μερικές λεπτομέρειες:

  1. Στο πρωτόκολλο source υποδεικνύεται η διεύθυνση στο χώρο αποθήκευσης στο Ceph RBD (αυτή είναι η διεύθυνση που υποδεικνύει το όνομα της πισίνας Ceph και την εικόνα RBD, η οποία καθορίστηκε στο πρώτο στάδιο).
  2. Στο μπλοκ secret υποδεικνύεται ο τύπος ceph, καθώς και το UUID του μυστικού για να συνδεθείτε σε αυτό. Το uuid του μπορεί να βρεθεί χρησιμοποιώντας την εντολή virsh secret-list.
  3. Στο μπλοκ host υποδεικνύονται οι διευθύνσεις σε οθόνες Ceph.

Μετά την επεξεργασία του αρχείου διαμόρφωσης και την ολοκλήρωση της μετατροπής LVM σε RBD, μπορείτε να εφαρμόσετε το τροποποιημένο αρχείο διαμόρφωσης και να ξεκινήσετε την εικονική μηχανή:

virsh define $vm_name.xml
virsh start $vm_name

Ήρθε η ώρα να ελέγξετε ότι η εικονική μηχανή ξεκίνησε σωστά: μπορείτε να μάθετε, για παράδειγμα, συνδέοντάς της μέσω SSH ή μέσω virsh.

Εάν η εικονική μηχανή λειτουργεί σωστά και δεν έχετε βρει άλλα προβλήματα, τότε μπορείτε να διαγράψετε την εικόνα LVM που δεν χρησιμοποιείται πλέον:

lvremove main/$vm_image_name

Συμπέρασμα

Συναντήσαμε όλες τις περιγραφόμενες περιπτώσεις στην πράξη - ελπίζουμε ότι οι οδηγίες θα βοηθήσουν άλλους διαχειριστές να επιλύσουν παρόμοια προβλήματα. Εάν έχετε σχόλια ή άλλες παρόμοιες ιστορίες από την εμπειρία σας χρησιμοποιώντας το Ceph, θα χαρούμε να τις δούμε στα σχόλια!

PS

Διαβάστε επίσης στο blog μας:

Πηγή: www.habr.com

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