Σε αυτό το άρθρο, θα μιλήσω για μια κατάσταση που συνέβη πρόσφατα με έναν από τους διακομιστές στο νέφος VPS μας, που με άφησε μπερδεμένο για αρκετές ώρες. Διαμορφώνω και αντιμετωπίζω προβλήματα διακομιστών Linux για περίπου 15 χρόνια, αλλά αυτή η περίπτωση δεν ταιριάζει καθόλου στην πρακτική μου - έκανα αρκετές ψευδείς υποθέσεις και απελπίστηκα λίγο πριν καταφέρω να προσδιορίσω σωστά την αιτία του προβλήματος και να το λύσω .
Προοίμιο
Λειτουργούμε ένα μεσαίου μεγέθους cloud, το οποίο χτίζουμε σε τυπικούς διακομιστές με την ακόλουθη διαμόρφωση - 32 πυρήνες, 256 GB RAM και μονάδα δίσκου PCI-E Intel P4500 NVMe 4 TB. Μας αρέσει πολύ αυτή η διαμόρφωση, επειδή εξαλείφει την ανάγκη να ανησυχείτε για την επιβάρυνση IO παρέχοντας τον σωστό περιορισμό σε επίπεδο τύπου παρουσίας VM. Επειδή η NVMe Intel έχει εντυπωσιακή απόδοση, μπορούμε ταυτόχρονα να παρέχουμε πλήρη παροχή IOPS σε μηχανήματα και εφεδρική αποθήκευση σε έναν διακομιστή αντιγράφων ασφαλείας με μηδενικό IOWAIT.
Είμαστε από εκείνους τους παλιούς πιστούς που δεν χρησιμοποιούν υπερσυγκλίνοντα SDN και άλλα κομψά, μοντέρνα, νεανικά πράγματα για την αποθήκευση τόμων VM, πιστεύοντας ότι όσο πιο απλό είναι το σύστημα, τόσο πιο εύκολο είναι να το αντιμετωπίσουμε υπό τις συνθήκες του «ο κύριος γκουρού έχει φύγει στα βουνά." Ως αποτέλεσμα, αποθηκεύουμε τόμους VM σε μορφή QCOW2 σε XFS ή EXT4, το οποίο αναπτύσσεται πάνω από το LVM2.
Αναγκαζόμαστε επίσης να χρησιμοποιήσουμε το QCOW2 από το προϊόν που χρησιμοποιούμε για ενορχήστρωση - Apache CloudStack.
Για να δημιουργήσουμε ένα αντίγραφο ασφαλείας, παίρνουμε μια πλήρη εικόνα του τόμου ως στιγμιότυπο LVM2 (ναι, γνωρίζουμε ότι τα στιγμιότυπα του LVM2 είναι αργά, αλλά το Intel P4500 μας βοηθά και εδώ). Κανουμε lvmcreate -s .. και με τη βοήθεια dd στέλνουμε το αντίγραφο ασφαλείας σε έναν απομακρυσμένο διακομιστή με χώρο αποθήκευσης ZFS. Εδώ είμαστε ακόμα ελαφρώς προοδευτικοί - τελικά, το ZFS μπορεί να αποθηκεύσει δεδομένα σε συμπιεσμένη μορφή και μπορούμε να τα επαναφέρουμε γρήγορα χρησιμοποιώντας DD ή λάβετε μεμονωμένους τόμους VM χρησιμοποιώντας mount -o loop ....
Μπορείτε, φυσικά, να αφαιρέσετε όχι την πλήρη εικόνα του τόμου LVM2, αλλά να προσαρτήσετε το σύστημα αρχείων στο
ROκαι αντιγράψτε τις ίδιες τις εικόνες QCOW2, ωστόσο, βρεθήκαμε αντιμέτωποι με το γεγονός ότι το XFS έγινε κακό από αυτό, και όχι αμέσως, αλλά με απρόβλεπτο τρόπο. Πραγματικά δεν μας αρέσει όταν οι οικοδεσπότες hypervisor «κολλάνε» ξαφνικά τα Σαββατοκύριακα, τη νύχτα ή τις αργίες λόγω σφαλμάτων που δεν είναι σαφές πότε θα συμβούν. Επομένως, για το XFS δεν χρησιμοποιούμε τοποθέτηση στιγμιότυπουROγια να εξαγάγουμε τόμους, απλώς αντιγράφουμε ολόκληρο τον τόμο LVM2.
Η ταχύτητα δημιουργίας αντιγράφων ασφαλείας στον εφεδρικό διακομιστή καθορίζεται στην περίπτωσή μας από την απόδοση του διακομιστή αντιγράφων ασφαλείας, που είναι περίπου 600-800 MB/s για ασυμπίεστα δεδομένα· ένας περαιτέρω περιοριστής είναι το κανάλι 10 Gbit/s με το οποίο είναι συνδεδεμένος ο διακομιστής αντιγράφων ασφαλείας στο σύμπλεγμα.
Σε αυτήν την περίπτωση, αντίγραφα αντιγράφων ασφαλείας 8 διακομιστών hypervisor φορτώνονται ταυτόχρονα σε έναν διακομιστή αντιγράφων ασφαλείας. Έτσι, ο δίσκος και τα υποσυστήματα δικτύου του εφεδρικού διακομιστή, όντας πιο αργά, δεν επιτρέπουν στα υποσυστήματα δίσκου των κεντρικών υπολογιστών hypervisor να υπερφορτωθούν, αφού απλά δεν μπορούν να επεξεργαστούν, ας πούμε, 8 GB/sec, τα οποία μπορούν εύκολα να φιλοξενήσουν οι κεντρικοί υπολογιστές hypervisor. παράγω.
Η παραπάνω διαδικασία αντιγραφής είναι πολύ σημαντική για την περαιτέρω ιστορία, συμπεριλαμβανομένων των λεπτομερειών - χρησιμοποιώντας μια γρήγορη μονάδα δίσκου Intel P4500, χρησιμοποιώντας NFS και, πιθανώς, χρησιμοποιώντας ZFS.
Εφεδρική ιστορία
Σε κάθε κόμβο hypervisor έχουμε ένα μικρό διαμέρισμα SWAP μεγέθους 8 GB και «ξεκινάμε» τον ίδιο τον κόμβο hypervisor χρησιμοποιώντας DD από την εικόνα αναφοράς. Για τον όγκο του συστήματος στους διακομιστές, χρησιμοποιούμε 2xSATA SSD RAID1 ή 2xSAS HDD RAID1 σε ελεγκτή υλικού LSI ή HP. Γενικά, δεν μας ενδιαφέρει καθόλου τι υπάρχει μέσα, καθώς ο όγκος του συστήματός μας λειτουργεί σε λειτουργία "σχεδόν μόνο για ανάγνωση", εκτός από το SWAP. Και επειδή έχουμε πολλή μνήμη RAM στον διακομιστή και είναι 30-40% δωρεάν, δεν σκεφτόμαστε το SWAP.
Διαδικασία δημιουργίας αντιγράφων ασφαλείας. Αυτή η εργασία μοιάζει κάπως έτσι:
#!/bin/bash
mkdir -p /mnt/backups/volumes
DIR=/mnt/images-snap
VOL=images/volume
DATE=$(date "+%d")
HOSTNAME=$(hostname)
lvcreate -s -n $VOL-snap -l100%FREE $VOL
ionice -c3 dd iflag=direct if=/dev/$VOL-snap bs=1M of=/mnt/backups/volumes/$HOSTNAME-$DATE.raw
lvremove -f $VOL-snapΔώστε προσοχή ionice -c3, στην πραγματικότητα, αυτό το πράγμα είναι εντελώς άχρηστο για συσκευές NVMe, αφού ο προγραμματιστής IO για αυτές έχει οριστεί ως:
cat /sys/block/nvme0n1/queue/scheduler
[none] Ωστόσο, έχουμε αρκετούς κόμβους παλαιού τύπου με συμβατικά RAID SSD, γι' αυτούς αυτό είναι σχετικό, επομένως κινούνται ΟΠΩΣ ΕΙΝΑΙ. Συνολικά, αυτό είναι απλώς ένα ενδιαφέρον κομμάτι κώδικα που εξηγεί τη ματαιότητα ionice σε περίπτωση τέτοιας διαμόρφωσης.
Προσοχή στη σημαία iflag=direct για DD. Χρησιμοποιούμε απευθείας IO παρακάμπτοντας την προσωρινή μνήμη προσωρινής αποθήκευσης για να αποφύγουμε την περιττή αντικατάσταση των buffer IO κατά την ανάγνωση. Ωστόσο, oflag=direct δεν το κάνουμε επειδή αντιμετωπίσαμε προβλήματα απόδοσης του ZFS κατά τη χρήση του.
Χρησιμοποιούμε αυτό το σχήμα με επιτυχία εδώ και αρκετά χρόνια χωρίς προβλήματα.
Και μετά άρχισε... Ανακαλύψαμε ότι ένας από τους κόμβους δεν είχε πλέον αντίγραφο ασφαλείας και ο προηγούμενος λειτουργούσε με ένα τερατώδες IOWAIT 50%. Όταν προσπαθούσαμε να καταλάβουμε γιατί δεν συμβαίνει η αντιγραφή, συναντήσαμε το ακόλουθο φαινόμενο:
Volume group "images" not foundΑρχίσαμε να σκεφτόμαστε «το τέλος για το Intel P4500 ήρθε», ωστόσο, πριν απενεργοποιήσουμε τον διακομιστή για να αντικαταστήσουμε τη μονάδα δίσκου, ήταν ακόμα απαραίτητο να δημιουργήσουμε ένα αντίγραφο ασφαλείας. Διορθώσαμε το LVM2 επαναφέροντας τα μεταδεδομένα από ένα αντίγραφο ασφαλείας του LVM2:
vgcfgrestore imagesΔημιουργήσαμε ένα αντίγραφο ασφαλείας και είδαμε αυτήν την ελαιογραφία:
Και πάλι ήμασταν πολύ λυπημένοι - ήταν ξεκάθαρο ότι δεν μπορούσαμε να ζήσουμε έτσι, αφού όλα τα VPS θα υποφέρουν, πράγμα που σημαίνει ότι θα υποφέρουμε και εμείς. Το τι συνέβη είναι εντελώς ασαφές - iostat έδειξε αξιολύπητη IOPS και την υψηλότερη IOWAIT. Δεν υπήρχαν άλλες ιδέες εκτός από το "ας αντικαταστήσουμε το NVMe", αλλά μια εικόνα προέκυψε την ώρα που έπρεπε.
Ανάλυση της κατάστασης βήμα προς βήμα
Ιστορικό περιοδικό. Λίγες μέρες νωρίτερα, σε αυτόν τον διακομιστή ήταν απαραίτητο να δημιουργηθεί ένα μεγάλο VPS με 128 GB RAM. Φαινόταν ότι υπήρχε αρκετή μνήμη, αλλά για να είμαστε ασφαλείς, διαθέσαμε άλλα 32 GB για το διαμέρισμα ανταλλαγής. Το VPS δημιουργήθηκε, ολοκλήρωσε με επιτυχία το έργο του και το περιστατικό ξεχάστηκε, αλλά το διαμέρισμα SWAP παρέμεινε.
Χαρακτηριστικά διαμόρφωσης. Για όλους τους διακομιστές cloud η παράμετρος vm.swappiness ορίστηκε ως προεπιλογή 60. Και το SWAP δημιουργήθηκε στο SAS HDD RAID1.
Τι συνέβη (σύμφωνα με τους συντάκτες). Κατά τη δημιουργία αντιγράφων ασφαλείας DD παρήγαγε πολλά δεδομένα εγγραφής, τα οποία τοποθετήθηκαν σε buffers RAM πριν εγγραφούν στο NFS. Πυρήνας συστήματος, με γνώμονα την πολιτική swappiness, μετακινούσε πολλές σελίδες μνήμης VPS στην περιοχή ανταλλαγής, η οποία βρισκόταν σε έναν αργό τόμο HDD RAID1. Αυτό οδήγησε στην πολύ ισχυρή ανάπτυξη του IOWAIT, αλλά όχι λόγω του IO NVMe, αλλά λόγω του IO HDD RAID1.
Πώς λύθηκε το πρόβλημα. Το διαμέρισμα swap 32 GB απενεργοποιήθηκε. Αυτό κράτησε 16 ώρες. Μπορείτε να διαβάσετε ξεχωριστά πώς και γιατί το SWAP απενεργοποιείται τόσο αργά. Οι ρυθμίσεις έχουν αλλάξει swappiness σε τιμή ίση με 5 σε όλο το σύννεφο.
Πώς θα μπορούσε να μην συμβεί αυτό;. Πρώτον, εάν το SWAP ήταν σε μια συσκευή SSD RAID ή NVMe και, δεύτερον, αν δεν υπήρχε συσκευή NVMe, αλλά μια πιο αργή συσκευή που δεν θα παρήγαγε τέτοιο όγκο δεδομένων - κατά ειρωνικό τρόπο, το πρόβλημα συνέβη επειδή αυτό το NVMe είναι πολύ γρήγορο.
Μετά από αυτό, όλα άρχισαν να λειτουργούν όπως πριν - με μηδέν IOWAIT.
Πηγή: www.habr.com