Ταχύτητα αποθήκευσης κατάλληλη για etcd; Ας ρωτήσουμε τον Φίο

Ταχύτητα αποθήκευσης κατάλληλη για etcd; Ας ρωτήσουμε τον Φίο

Μια σύντομη ιστορία για το fio και etcd

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

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

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

  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.
  • Κατά τη διάρκεια της δοκιμής, όλο το φορτίο I/O προέρχεται από το fio. Σε ένα πραγματικό σενάριο, πιθανότατα θα υπάρχουν και άλλα αιτήματα εγγραφής στο χώρο αποθήκευσης εκτός από αυτά που σχετίζονται με το wal_fsync_duration_seconds. Το επιπλέον φορτίο θα αυξήσει την τιμή των wal_fsync_duration_seconds. Έτσι, εάν το 99ο εκατοστημόριο είναι κοντά στα 10ms, ο αποθηκευτικός σας χώρος εξαντλείται.
  • Πάρτε την έκδοση fio όχι μικρότερο από 3.5 (τα προηγούμενα δεν εμφανίζουν εκατοστημόρια διάρκειας fdatasync).
  • Το παραπάνω είναι μόνο ένα απόσπασμα των αποτελεσμάτων από το fio.

Μεγάλη ιστορία για το fio και το etcd

Τι είναι το WAL σε κ.λπ

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

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

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

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

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

Εάν πρέπει να αξιολογήσετε εάν ο αποθηκευτικός σας χώρος είναι κατάλληλος για etcd, χρησιμοποιήστε το fio, ένα πολύ δημοφιλές εργαλείο δοκιμής φορτίου I/O. Θα πρέπει να θυμόμαστε ότι οι λειτουργίες του δίσκου μπορεί να είναι πολύ διαφορετικές: σύγχρονες και ασύγχρονες, πολλές κατηγορίες κλήσεων συστήματος κ.λπ. Ως αποτέλεσμα, το fio είναι αρκετά δύσκολο στη χρήση. Έχει πολλές παραμέτρους και διαφορετικοί συνδυασμοί των τιμών τους παράγουν πολύ διαφορετικούς φόρτους εργασίας I/O. Για να λάβετε επαρκή στοιχεία για το etcd, θα πρέπει να βεβαιωθείτε ότι το δοκιμαστικό φορτίο εγγραφής από το fio είναι όσο το δυνατόν πιο κοντά στο πραγματικό φορτίο από το etcd κατά τη σύνταξη αρχείων WAL.

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

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

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

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

Χρησιμοποιήσαμε για πρώτη φορά το strace για να εξερευνήσουμε τον διακομιστή etcd για το Kubernetes όταν δεν υπήρχε φόρτωση στο σύμπλεγμα. Είδαμε ότι σχεδόν όλες οι εγγραφές WAL είχαν περίπου το ίδιο μέγεθος: 2200–2400 byte. Επομένως, στην εντολή στην αρχή της ανάρτησης, καθορίσαμε την παράμετρο -bs=2300 (bs σημαίνει το μέγεθος σε byte για κάθε καταχώρηση fio). Σημειώστε ότι το μέγεθος της καταχώρισης etcd εξαρτάται από την έκδοση etcd, τη διανομή, τις τιμές παραμέτρων κ.λπ. και επηρεάζει τη διάρκεια fdatasync. Εάν έχετε ένα παρόμοιο σενάριο, εξετάστε τις διεργασίες σας etcd με strace για να μάθετε τους ακριβείς αριθμούς.

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

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

Έχουμε επιλέξει προσεκτικά την τιμή της παραμέτρου --size για να αντιπροσωπεύει ολόκληρο το φορτίο I/O από το fio. Στην περίπτωσή μας, αυτός είναι ο συνολικός αριθμός των byte που γράφτηκαν στον αποθηκευτικό χώρο. Αποδείχθηκε ότι ήταν ευθέως ανάλογο με τον αριθμό των κλήσεων συστήματος εγγραφής (και fdatasync). Για μια συγκεκριμένη τιμή του bs, ο αριθμός των κλήσεων fdatasync = μέγεθος/bs. Εφόσον μας ενδιέφερε το εκατοστημόριο, έπρεπε να έχουμε αρκετά δείγματα για να είμαστε σίγουροι και υπολογίσαμε ότι 10^4 θα ήταν αρκετά για εμάς (δηλαδή 22 mebibyte). Εάν το --size είναι μικρότερο, ενδέχεται να προκύψουν ακραίες τιμές (για παράδειγμα, αρκετές κλήσεις fdatasync διαρκούν περισσότερο από το συνηθισμένο και επηρεάζουν το 99ο εκατοστημόριο).

Δοκιμάστε το μόνοι σας

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

Πηγή: www.habr.com

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