🥇Πώς να ελέγξετε τους δίσκους με fio για επαρκή απόδοση για etcd

Σημείωση. μετάφρ.: Αυτό το άρθρο είναι το αποτέλεσμα μιας μίνι έρευνας που διεξήχθη από μηχανικούς της IBM Cloud για αναζήτηση λύσης σε ένα πραγματικό πρόβλημα που σχετίζεται με τη λειτουργία της βάσης δεδομένων etcd. Ένα παρόμοιο έργο ήταν σχετικό για εμάς, ωστόσο, η πορεία των προβληματισμών και των ενεργειών των συγγραφέων μπορεί να είναι ενδιαφέρουσα σε ένα ευρύτερο πλαίσιο.

Σύντομη περίληψη ολόκληρου του άρθρου: fio και κ.λπ

Η απόδοση ενός συμπλέγματος etcd εξαρτάται σε μεγάλο βαθμό από την ταχύτητα της υποκείμενης αποθήκευσης. Το etcd εξάγει διάφορες μετρήσεις του Prometheus για την παρακολούθηση της απόδοσης. Ένα από αυτά είναι wal_fsync_duration_seconds. Στην τεκμηρίωση για κ.λπ λέειότι η αποθήκευση μπορεί να θεωρηθεί αρκετά γρήγορη εάν το 99ο εκατοστημόριο αυτής της μέτρησης δεν υπερβαίνει τα 10 ms…

Εάν σκέφτεστε να δημιουργήσετε ένα σύμπλεγμα etcd σε μηχανές Linux και θέλετε να ελέγξετε εάν οι μονάδες δίσκου (όπως οι SSD) είναι αρκετά γρήγοροι, σας προτείνουμε να χρησιμοποιήσετε το δημοφιλές ελεγκτή I/O που ονομάζεται fio. Αρκεί να εκτελέσετε την παρακάτω εντολή (κατάλογος test-data πρέπει να βρίσκεται στο τοποθετημένο διαμέρισμα της δοκιμασμένης μονάδας δίσκου):

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

Απομένει μόνο να δούμε την έξοδο και να ελέγξουμε αν το 99ο εκατοστημόριο ταιριάζει fdatasync σε 10 ms. Αν ναι, τότε ο δίσκος σας λειτουργεί αρκετά γρήγορα. Ακολουθεί ένα παράδειγμα εξόδου:

fsync/fdatasync/sync_file_range:
  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]

Μερικές σημειώσεις:

Στο παραπάνω παράδειγμα, έχουμε προσαρμόσει τις παραμέτρους --size и --bs για μια συγκεκριμένη περίπτωση. Για να πάρετε ένα ουσιαστικό αποτέλεσμα από fio, καθορίστε τις κατάλληλες τιμές για την περίπτωση χρήσης σας. Ο τρόπος επιλογής τους θα συζητηθεί παρακάτω.
Μόνο κατά τη διάρκεια της δοκιμής fio φορτώνει το υποσύστημα του δίσκου. Στην πραγματική ζωή, είναι πιθανό ότι άλλες διεργασίες θα εγγραφούν στο δίσκο (εκτός από αυτές που σχετίζονται με wal_fsync_duration_seconds). Αυτό το πρόσθετο φορτίο μπορεί να αυξηθεί wal_fsync_duration_seconds. Με άλλα λόγια, εάν το 99ο εκατοστημόριο από τη δοκιμή με fio, μόνο λίγο λιγότερο από 10 ms, υπάρχει μεγάλη πιθανότητα η απόδοση αποθήκευσης να μην είναι επαρκής.
Για τη δοκιμή θα χρειαστείτε την έκδοση fio όχι μικρότερο από 3.5, επειδή οι παλαιότερες εκδόσεις δεν συγκεντρώνουν αποτελέσματα fdatasync με τη μορφή εκατοστημόνων.
Το παραπάνω συμπέρασμα είναι μόνο ένα μικρό απόσπασμα από το γενικό συμπέρασμα fio.

Περισσότερα για fio και etcd

Λίγα λόγια για τα WAL κ.λπ

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

Έτσι, κάθε φορά που ένας πελάτης προσθέτει ένα κλειδί στο χώρο αποθήκευσης KV ή ενημερώνει την τιμή ενός υπάρχοντος κλειδιού, κλπ. προσθέτει την περιγραφή της λειτουργίας στο WAL, το οποίο είναι ένα κανονικό αρχείο στο μόνιμο χώρο αποθήκευσης. κ.λπ. ΠΡΕΠΕΙ να είναι 100% σίγουρος ότι η καταχώρηση WAL έχει όντως αποθηκευτεί πριν συνεχίσετε. Για να επιτευχθεί αυτό στο Linux, δεν αρκεί να χρησιμοποιήσετε την κλήση συστήματος write, καθώς η ίδια η λειτουργία εγγραφής στα φυσικά μέσα ενδέχεται να καθυστερήσει. Για παράδειγμα, το Linux μπορεί να διατηρήσει μια καταχώρηση WAL σε μια κρυφή μνήμη του πυρήνα της μνήμης (π.χ. στη μνήμη cache της σελίδας) για κάποιο χρονικό διάστημα. Για να διασφαλιστεί ότι τα δεδομένα έχουν εγγραφεί στο μέσο, πρέπει να γίνει κλήση συστήματος μετά την εγγραφή fdatasync - αυτό ακριβώς κάνει το etcd (όπως μπορείτε να δείτε στην ακόλουθη έξοδο strace; Εδώ 8 - Περιγραφέας αρχείου WAL):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ".20210220361223255266632$1020103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

Δυστυχώς, η εγγραφή σε μόνιμο χώρο αποθήκευσης απαιτεί λίγο χρόνο. Η παρατεταμένη εκτέλεση κλήσεων fdatasync μπορεί να επηρεάσει την απόδοση του etcd. Στην τεκμηρίωση του αποθετηρίου υποδεικνύεται, ότι για επαρκή απόδοση είναι απαραίτητο το 99ο εκατοστημόριο της διάρκειας όλων των κλήσεων fdatasync όταν η εγγραφή σε ένα αρχείο WAL ήταν λιγότερο από 10 ms. Υπάρχουν και άλλες μετρήσεις που σχετίζονται με τον αποθηκευτικό χώρο, αλλά αυτό το άρθρο θα επικεντρωθεί σε αυτό.

Εκτίμηση της αποθήκευσης με το fio

Μπορείτε να αξιολογήσετε εάν μια συγκεκριμένη αποθήκευση είναι κατάλληλη για χρήση με etcd χρησιμοποιώντας το βοηθητικό πρόγραμμα fio — ένας δημοφιλής ελεγκτής I/O. Λάβετε υπόψη ότι η είσοδος/έξοδος του δίσκου μπορεί να συμβεί με πολλούς διαφορετικούς τρόπους: συγχρονισμός/ασυγχρονισμός, πολλές διαφορετικές κλάσεις syscall και ούτω καθεξής. Η άλλη όψη του νομίσματος είναι αυτή fio εξαιρετικά δύσκολο στη χρήση. Το βοηθητικό πρόγραμμα έχει πολλές παραμέτρους και διαφορετικοί συνδυασμοί των τιμών τους οδηγούν σε εντελώς διαφορετικά αποτελέσματα. Για να λάβετε μια λογική εκτίμηση για το etcd, πρέπει να βεβαιωθείτε ότι το φορτίο εγγραφής που δημιουργείται από το fio είναι όσο το δυνατόν πιο κοντά στο φορτίο εγγραφής του αρχείου WAL του etcd:

Αυτό σημαίνει ότι το παραγόμενο fio το φορτίο θα πρέπει να είναι τουλάχιστον μια σειρά από διαδοχικές εγγραφές στο αρχείο, όπου κάθε εγγραφή αποτελείται από μια κλήση συστήματος writeακολουθούμενη από fdatasync.
Για να ενεργοποιήσετε τη διαδοχική εγγραφή, πρέπει να καθορίσετε τη σημαία --rw=write.
Ότι fio έγραψε χρησιμοποιώντας κλήσεις write (και όχι άλλες κλήσεις συστήματος - για παράδειγμα, pwrite), χρησιμοποιήστε τη σημαία --ioengine=sync.
Τέλος, η σημαία --fdatasync=1 εξασφαλίζει ότι κάθε write πρέπει να είναι fdatasync.
Οι άλλες δύο παράμετροι στο παράδειγμά μας είναι: --size и --bs - ενδέχεται να διαφέρει ανάλογα με τη συγκεκριμένη περίπτωση χρήσης. Η επόμενη ενότητα θα περιγράψει τη διαμόρφωσή τους.

Γιατί επιλέξαμε το fio και πώς μάθαμε πώς να το στήνουμε

Αυτό το σημείωμα προέρχεται από μια πραγματική υπόθεση που συναντήσαμε. Είχαμε ένα σύμπλεγμα στο Kubernetes v1.13 με παρακολούθηση στον Προμηθέα. Οι SSD χρησιμοποιήθηκαν ως αποθήκευση για etcd v3.2.24. Οι μετρήσεις Etcd έδειξαν πολύ υψηλές καθυστερήσεις fdatasync, ακόμα και όταν το σύμπλεγμα ήταν αδρανές. Σε εμάς, αυτές οι μετρήσεις φάνηκαν πολύ αμφίβολες και δεν ήμασταν σίγουροι τι ακριβώς αντιπροσώπευαν. Επιπλέον, το cluster αποτελούνταν από εικονικές μηχανές, οπότε δεν ήταν δυνατό να πούμε αν η καθυστέρηση οφείλεται σε virtualization ή έφταιγε ο SSD.

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

Αυτό απαιτούσε την επίλυση δύο προβλημάτων:

Πρώτον, πώς μοιάζει το φορτίο I/O που δημιουργείται από το etcd κατά την εγγραφή σε αρχεία WAL; Ποιες κλήσεις συστήματος χρησιμοποιούνται; Ποιο είναι το μέγεθος των μπλοκ εγγραφής;
Δεύτερον, ας πούμε ότι έχουμε απαντήσεις στα παραπάνω ερωτήματα. Πώς να αναπαράγετε το αντίστοιχο φορτίο με fio? Παρά όλα αυτά fio — εξαιρετικά ευέλικτη χρησιμότητα με πληθώρα παραμέτρων (αυτό είναι εύκολο να επαληθευτεί, για παράδειγμα, εδώ - περίπου μετάφρ.).

Επιλύσαμε και τα δύο προβλήματα με την ίδια προσέγγιση βασισμένη σε εντολές lsof и strace:

Με lsof μπορείτε να δείτε όλους τους περιγραφείς αρχείων που χρησιμοποιούνται από τη διαδικασία, καθώς και τα αρχεία στα οποία αναφέρονται.
Με strace μπορείτε να αναλύσετε μια ήδη εκτελούμενη διαδικασία ή να εκτελέσετε μια διαδικασία και να την παρακολουθήσετε. Η εντολή εμφανίζει όλες τις κλήσεις συστήματος που πραγματοποιούνται από αυτήν τη διαδικασία και, εάν είναι απαραίτητο, τους απογόνους της. Το τελευταίο είναι σημαντικό για διεργασίες που διαχωρίζονται και το etcd είναι μια τέτοια διαδικασία.

Το πρώτο πράγμα που κάναμε ήταν να χρησιμοποιήσουμε strace για να εξετάσετε τον διακομιστή etcd στο σύμπλεγμα Kubernetes ενώ ήταν αδρανής.

Έτσι, διαπιστώθηκε ότι τα μπλοκ εγγραφής WAL είναι πολύ πυκνά ομαδοποιημένα, το μέγεθος της πλειοψηφίας ήταν στην περιοχή των 2200-2400 byte. Γι' αυτό η εντολή στην αρχή αυτού του άρθρου χρησιμοποιεί τη σημαία --bs=2300 (bs είναι το μέγεθος σε byte κάθε μπλοκ εγγραφής μέσα fio).

Λάβετε υπόψη ότι το μέγεθος των μπλοκ εγγραφής etcd μπορεί να διαφέρει ανάλογα με την έκδοση, την ανάπτυξη, τις τιμές παραμέτρων κ.λπ. - επηρεάζει τη διάρκεια fdatasync. Εάν έχετε παρόμοια περίπτωση χρήσης, αναλύστε με strace διεργασίες σας etcd για να λάβετε ενημερωμένες τιμές.

Στη συνέχεια, για να έχουμε μια σαφή και ολοκληρωμένη ιδέα για το πώς λειτουργεί το etcd με το σύστημα αρχείων, το ξεκινήσαμε από κάτω strace με σημαίες -ffttT. Αυτό κατέστησε δυνατή την καταγραφή των θυγατρικών διεργασιών και την εγγραφή των αποτελεσμάτων καθεμιάς σε ένα ξεχωριστό αρχείο. Επιπλέον, ελήφθησαν λεπτομερείς πληροφορίες σχετικά με την ώρα έναρξης και τη διάρκεια κάθε κλήσης συστήματος.

Χρησιμοποιήσαμε επίσης την εντολή lsofγια να επιβεβαιώσετε την κατανόησή σας για την έξοδο strace ως προς το ποιος περιγραφέας αρχείου χρησιμοποιήθηκε για ποιο σκοπό. Πήρα το συμπέρασμα strace, παρόμοιο με το παραπάνω. Οι στατιστικοί χειρισμοί με τους χρόνους συγχρονισμού επιβεβαίωσαν ότι η μέτρηση wal_fsync_duration_seconds από κλήσεις κ.λπ fdatasync με περιγραφείς αρχείων WAL.

Για να δημιουργήσετε με fio φόρτο εργασίας παρόμοιο με αυτό από το etcd, μελετήθηκε η τεκμηρίωση του βοηθητικού προγράμματος και επιλέχθηκαν οι κατάλληλες παράμετροι για την εργασία μας. Επαληθεύσαμε ότι οι σωστές κλήσεις συστήματος βρίσκονται σε εξέλιξη και επιβεβαιώσαμε τη διάρκειά τους εκτελώντας fio του strace (όπως έγινε στην περίπτωση κ.λπ.).

Ιδιαίτερη προσοχή δόθηκε στον προσδιορισμό της τιμής της παραμέτρου --size. Αντιπροσωπεύει το συνολικό φορτίο I/O που δημιουργείται από το βοηθητικό πρόγραμμα fio. Στην περίπτωσή μας, αυτός είναι ο συνολικός αριθμός των byte που γράφτηκαν στα μέσα. Είναι ευθέως ανάλογο με τον αριθμό των κλήσεων write (και fdatasync). Για ένα συγκεκριμένο bs αριθμός κλήσεων fdatasync ισούται με size / bs.

Επειδή μας ενδιέφερε το εκατοστημόριο, θέλαμε ο αριθμός των δειγμάτων να είναι αρκετά μεγάλος ώστε να είναι στατιστικά σημαντικός. Και το αποφάσισε 10^4 (που αντιστοιχεί σε μέγεθος 22 MB) θα είναι αρκετό. Μικρότερες τιμές παραμέτρων --size έδωσε πιο έντονο θόρυβο (για παράδειγμα, κλήσεις fdatasync, τα οποία διαρκούν πολύ περισσότερο από το συνηθισμένο και επηρεάζουν το 99ο εκατοστημόριο).

Από σένα εξαρτάται

Το άρθρο δείχνει πώς να το χρησιμοποιήσετε fio μπορεί κανείς να κρίνει εάν τα μέσα που προορίζονται για χρήση με etcd είναι αρκετά γρήγορα. Τώρα εξαρτάται από εσάς! Μπορείτε να εξερευνήσετε εικονικές μηχανές με αποθηκευτικό χώρο που βασίζεται σε SSD στην υπηρεσία IBM Cloud.

ΥΓ από τον μεταφραστή

Με έτοιμες θήκες χρήσης fio Για άλλες εργασίες, βλ τεκμηρίωση ή απευθείας σε αποθετήρια έργων (είναι πολλά περισσότερα από αυτά που αναφέρονται στην τεκμηρίωση).

PPS από τον μεταφραστή

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

Πηγή: www.habr.com

Πώς να ελέγξετε τους δίσκους με το fio για επαρκή απόδοση για etcd