Στα τέλη του περασμένου έτους, πραγματοποιήθηκε άλλη μια ζωντανή μετάδοση της ρωσικής κοινότητας PostgreSQL , κατά τη διάρκεια της οποίας ο συνιδρυτής του Nikolai Samokhvalov μίλησε με τον τεχνικό διευθυντή της Flan Dmitry Stolyarov σχετικά με αυτό το DBMS στο πλαίσιο του Kubernetes.
Δημοσιεύουμε μια απομαγνητοφώνηση του κύριου μέρους αυτής της συζήτησης, και στο Ολόκληρο το βίντεο που δημοσιεύτηκε:
Βάσεις δεδομένων και Kubernetes
NS: Δεν θα μιλήσουμε για ΚΕΝΟ και ΣΗΜΕΙΑ ΕΛΕΓΧΟΥ σήμερα. Θέλουμε να μιλήσουμε για Kubernetes. Ξέρω ότι έχεις πολυετή εμπειρία. Παρακολούθησα τα βίντεό σας και μάλιστα ξαναείδα κάποια από αυτά... Ας πάμε κατευθείαν στο θέμα: γιατί καθόλου Postgres ή MySQL στα K8;
DS: Δεν υπάρχει και δεν μπορεί να υπάρξει σαφής απάντηση σε αυτό το ερώτημα. Αλλά γενικά, αυτό είναι απλότητα και ευκολία... δυνατότητες. Όλοι θέλουν διαχειριζόμενες υπηρεσίες.
NS: Για το πώς , μόνο στο σπίτι;
DS: Ναι: όπως το RDS, οπουδήποτε.
NS: Το "Anywhere" είναι ένα καλό σημείο. Στις μεγάλες εταιρείες, τα πάντα βρίσκονται σε διαφορετικά μέρη. Γιατί τότε, αν είναι μεγάλη εταιρεία, να μην πάρει μια έτοιμη λύση; Για παράδειγμα, η Nutanix έχει τις δικές της εξελίξεις, άλλες εταιρείες (VMware...) έχουν το ίδιο «RDS, μόνο στο σπίτι».
DS: Αλλά μιλάμε για μια ξεχωριστή υλοποίηση που θα λειτουργήσει μόνο υπό προϋποθέσεις. Και αν μιλάμε για Kubernetes, τότε υπάρχει μια τεράστια ποικιλία υποδομών (που μπορεί να είναι στα K8). Ουσιαστικά αυτό είναι ένα πρότυπο για τα API στο cloud...
NS: Είναι επίσης δωρεάν!
DS: Δεν είναι τόσο σημαντικό. Η ελευθερία είναι σημαντική για ένα όχι πολύ μεγάλο τμήμα της αγοράς. Κάτι άλλο είναι σημαντικό... Μάλλον θυμάστε την έκθεση «";
NS: Ναί.
DS: Κατάλαβα ότι έγινε δεκτό πολύ διφορούμενα. Κάποιοι νόμιζαν ότι έλεγα: «Παιδιά, ας βάλουμε όλες τις βάσεις δεδομένων στο Kubernetes!», ενώ άλλοι αποφάσισαν ότι όλα αυτά ήταν τρομερά ποδήλατα. Ήθελα όμως να πω κάτι εντελώς διαφορετικό: «Κοιτάξτε τι συμβαίνει, τι προβλήματα υπάρχουν και πώς μπορούν να λυθούν. Πρέπει να χρησιμοποιήσουμε βάσεις δεδομένων Kubernetes τώρα; Παραγωγή? Λοιπόν, μόνο αν σας αρέσει να κάνετε ορισμένα πράγματα. Αλλά για έναν προγραμματιστή, μπορώ να πω ότι το προτείνω. Για έναν προγραμματιστή, ο δυναμισμός της δημιουργίας/διαγραφής περιβαλλόντων είναι πολύ σημαντικός.”
NS: Με τον όρο dev, εννοείτε όλα τα περιβάλλοντα που δεν είναι prod; Staging, QA…
DS: Αν μιλάμε για περίπτερα, τότε μάλλον όχι, γιατί εκεί οι απαιτήσεις είναι συγκεκριμένες. Αν μιλάμε για ειδικές περιπτώσεις που χρειάζεται μια πολύ μεγάλη βάση δεδομένων για σταδιοποίηση, τότε μάλλον όχι... Εάν πρόκειται για ένα στατικό περιβάλλον με μεγάλη διάρκεια ζωής, τότε ποιο είναι το όφελος από την τοποθεσία της βάσης δεδομένων στα K8s;
NS: Κανένα. Πού όμως βλέπουμε στατικά περιβάλλοντα; Ένα στατικό περιβάλλον θα καταστεί παρωχημένο αύριο.
DS: Η σταδιοποίηση μπορεί να είναι στατική. Έχουμε πελάτες...
NS: Ναι, έχω κι εγώ ένα. Είναι μεγάλο πρόβλημα αν έχετε μια βάση δεδομένων 10 TB και σταδιοποίηση 200 GB...
DS: Έχω μια πολύ δροσερή υπόθεση! Κατά τη σταδιοποίηση υπάρχει μια βάση δεδομένων προϊόντων στην οποία γίνονται αλλαγές. Και υπάρχει ένα κουμπί: "κυκλοφόρησε στην παραγωγή". Αυτές οι αλλαγές -δέλτα- προστίθενται (φαίνεται ότι απλώς συγχρονίζονται μέσω του API) στην παραγωγή. Αυτή είναι μια πολύ εξωτική επιλογή.
NS: Έχω δει startups στο Valley που κάθονται στο RDS ή ακόμα και στο Heroku -αυτές είναι ιστορίες πριν από 2-3 χρόνια- και κατεβάζουν το dump στο laptop τους. Επειδή η βάση δεδομένων είναι ακόμα μόνο 80 GB, και υπάρχει χώρος στο φορητό υπολογιστή. Στη συνέχεια αγοράζουν επιπλέον δίσκους για όλους ώστε να έχουν 3 βάσεις δεδομένων για να πραγματοποιούν διαφορετικές εξελίξεις. Έτσι συμβαίνει και αυτό. Είδα επίσης ότι δεν φοβούνται να αντιγράψουν το prod στη σκηνή - εξαρτάται πολύ από την εταιρεία. Αλλά είδα επίσης ότι φοβούνται πολύ, και ότι συχνά δεν έχουν αρκετό χρόνο και χέρια. Αλλά πριν προχωρήσουμε σε αυτό το θέμα, θέλω να ακούσω για το Kubernetes. Καταλαβαίνω καλά ότι κανείς δεν είναι ακόμα στο prod;
DS: Έχουμε μικρές βάσεις δεδομένων στην παραγωγή. Μιλάμε για όγκους δεκάδων gigabyte και μη κρίσιμες υπηρεσίες για τις οποίες ήμασταν πολύ τεμπέληδες να φτιάξουμε αντίγραφα (και δεν υπάρχει τέτοια ανάγκη). Και με την προϋπόθεση ότι υπάρχει κανονική αποθήκευση κάτω από το Kubernetes. Αυτή η βάση δεδομένων λειτουργούσε σε μια εικονική μηχανή - υπό όρους σε VMware, πάνω από το σύστημα αποθήκευσης. Το τοποθετήσαμε μέσα και τώρα μπορούμε να το μεταφέρουμε από μηχανή σε μηχανή.
NS: Βάσεις δεδομένων αυτού του μεγέθους, έως 100 GB, μπορούν να κυκλοφορήσουν σε λίγα λεπτά σε καλούς δίσκους και καλό δίκτυο, σωστά; Η ταχύτητα 1 GB ανά δευτερόλεπτο δεν είναι πλέον εξωτική.
DS: Ναι, για γραμμική λειτουργία αυτό δεν είναι πρόβλημα.
NS: Εντάξει, πρέπει απλώς να σκεφτούμε την παραγωγή. Και αν σκεφτόμαστε το Kubernetes για περιβάλλοντα χωρίς παραγωγή, τι πρέπει να κάνουμε; Το βλέπω στο Zalando , στο Crunchy , υπάρχουν κάποιες άλλες επιλογές. Και υπάρχει - αυτός είναι ο καλός μας φίλος Alvaro από την Ισπανία: αυτό που κάνουν ουσιαστικά δεν είναι μόνο και ολόκληρη η διανομή (), στο οποίο, εκτός από την ίδια την Postgres, αποφάσισαν να βάλουν και ένα αντίγραφο ασφαλείας, τον πληρεξούσιο Envoy...
DS: Απεσταλμένος για τι; Εξισορρόπηση της κυκλοφορίας Postgres συγκεκριμένα;
NS: Ναί. Δηλαδή, το βλέπουν ως εξής: εάν πάρετε μια διανομή Linux και έναν πυρήνα, τότε η κανονική PostgreSQL είναι ο πυρήνας και θέλουν να κάνουν μια διανομή που θα είναι φιλική στο cloud και θα τρέχει στο Kubernetes. Συναρμολογούν στοιχεία (αντίγραφα ασφαλείας κ.λπ.) και τα διορθώνουν ώστε να λειτουργούν καλά.
DS: Πολύ κουλ! Ουσιαστικά αυτό είναι λογισμικό για να δημιουργήσετε το δικό σας διαχειριζόμενο Postgres.
NS: Οι διανομές Linux έχουν αιώνια προβλήματα: πώς να φτιάξετε προγράμματα οδήγησης ώστε να υποστηρίζεται όλο το υλικό. Και έχουν την ιδέα ότι θα δουλέψουν στο Kubernetes. Γνωρίζω ότι στον χειριστή Zalando είδαμε πρόσφατα μια σύνδεση με το AWS και αυτό δεν είναι πλέον πολύ καλό. Δεν πρέπει να υπάρχει σχέση με μια συγκεκριμένη υποδομή - ποιο είναι το νόημα;
DS: Δεν ξέρω ακριβώς σε ποια κατάσταση βρέθηκε ο Zalando, αλλά στο Kubernetes η αποθήκευση γίνεται πλέον με τέτοιο τρόπο που είναι αδύνατο να ληφθεί αντίγραφο ασφαλείας δίσκου χρησιμοποιώντας μια γενική μέθοδο. Πρόσφατα σε standard - στην τελευταία έκδοση — κάναμε δυνατά στιγμιότυπα, αλλά πού εφαρμόζεται; Ειλικρινά, όλα είναι ακόμα τόσο ακατέργαστα... Δοκιμάζουμε το CSI πάνω από τα AWS, GCE, Azure, vSphere, αλλά μόλις αρχίσετε να το χρησιμοποιείτε, μπορείτε να δείτε ότι δεν είναι ακόμα έτοιμο.
NS: Γι' αυτό μερικές φορές πρέπει να βασιζόμαστε σε υποδομές. Νομίζω ότι αυτό είναι ακόμα ένα πρώιμο στάδιο - αυξανόμενοι πόνοι. Ερώτηση: Τι συμβουλή θα δίνατε στους αρχάριους που θέλουν να δοκιμάσουν την PgSQL σε K8s; Ποιος χειριστής ίσως;
DS: Το πρόβλημα είναι ότι η Postgres είναι 3% για εμάς. Έχουμε επίσης μια πολύ μεγάλη λίστα διαφορετικών λογισμικών στο Kubernetes, δεν θα αναφέρω καν τα πάντα. Για παράδειγμα, Elasticsearch. Υπάρχουν πολλοί χειριστές: κάποιοι αναπτύσσονται ενεργά, άλλοι όχι. Έχουμε καταρτίσει απαιτήσεις για τους εαυτούς μας σχετικά με το τι πρέπει να έχει ένας χειριστής προκειμένου να το λάβουμε σοβαρά υπόψη. Σε έναν χειριστή ειδικά για την Kubernetes - όχι σε έναν "χειριστή για να κάνει κάτι υπό τις συνθήκες του Amazon"... Στην πραγματικότητα, πολύ ευρέως (= σχεδόν όλοι οι πελάτες) χρησιμοποιούμε έναν μόνο χειριστή - (θα δημοσιεύσουμε σύντομα ένα άρθρο για αυτόν).
NS: Και ούτε για MySQL; Γνωρίζω ότι η Percona... αφού τώρα εργάζονται σε MySQL, MongoDB και Postgres, θα πρέπει να δημιουργήσουν κάποιου είδους καθολική λύση: για όλες τις βάσεις δεδομένων, για όλους τους παρόχους cloud.
DS: Δεν είχαμε χρόνο να δούμε τους τελεστές για MySQL. Δεν είναι αυτός ο κύριος στόχος μας αυτή τη στιγμή. Η MySQL λειτουργεί καλά σε αυτόνομο. Γιατί να χρησιμοποιήσετε έναν τελεστή εάν μπορείτε απλώς να εκκινήσετε μια βάση δεδομένων... Μπορείτε να εκκινήσετε ένα κοντέινερ Docker με το Postrges ή μπορείτε να το εκκινήσετε με απλό τρόπο.
NS: Υπήρχε μια ερώτηση και για αυτό. Κανένας χειριστής;
DS: Ναι, το 100% από εμάς εκτελείται η PostgreSQL χωρίς τελεστή. Μέχρι στιγμής. Χρησιμοποιούμε ενεργά τον χειριστή για Prometheus και Redis. Έχουμε σχέδια να βρούμε έναν χειριστή για το Elasticsearch - είναι αυτός που είναι πιο «φωτιά», επειδή θέλουμε να τον εγκαταστήσουμε στο Kubernetes στο 100% των περιπτώσεων. Όπως ακριβώς θέλουμε να διασφαλίσουμε ότι το MongoDB είναι επίσης πάντα εγκατεστημένο στο Kubernetes. Εδώ εμφανίζονται ορισμένες επιθυμίες - υπάρχει η αίσθηση ότι σε αυτές τις περιπτώσεις κάτι μπορεί να γίνει. Και δεν κοιτάξαμε καν την Postgres. Φυσικά, γνωρίζουμε ότι υπάρχουν διαφορετικές επιλογές, αλλά στην πραγματικότητα έχουμε μια αυτόνομη.
DB για δοκιμή στο Kubernetes
NS: Ας περάσουμε στο θέμα των δοκιμών. Πώς να αναπτύξετε αλλαγές στη βάση δεδομένων - από την προοπτική του DevOps. Υπάρχουν μικροϋπηρεσίες, πολλές βάσεις δεδομένων, κάτι αλλάζει κάπου συνεχώς. Πώς να εξασφαλίσετε κανονικό CI/CD, ώστε όλα να είναι εντάξει από την άποψη του DBMS. Ποια είναι η προσέγγισή σας;
DS: Δεν μπορεί να υπάρχει μία απάντηση. Υπάρχουν πολλές επιλογές. Το πρώτο είναι το μέγεθος της βάσης που θέλουμε να απλώσουμε. Εσείς ο ίδιος αναφέρατε ότι οι εταιρείες έχουν διαφορετική στάση απέναντι στην ύπαρξη αντιγράφου της βάσης δεδομένων prod σε dev και stage.
NS: Και υπό τις συνθήκες του GDPR νομίζω ότι προσέχουν όλο και περισσότερο... Μπορώ να πω ότι στην Ευρώπη έχουν ήδη αρχίσει να επιβάλλουν πρόστιμα.
DS: Συχνά, όμως, μπορείτε να γράψετε λογισμικό που αφαιρεί μια απόρριψη από την παραγωγή και το θολώνει. Λαμβάνονται δεδομένα παραγωγής (στιγμιότυπο, απόθεση, δυαδικό αντίγραφο...), αλλά είναι ανώνυμα. Αντίθετα, μπορεί να υπάρχουν σενάρια παραγωγής: αυτά μπορεί να είναι φωτιστικά ή απλώς ένα σενάριο που δημιουργεί μια μεγάλη βάση δεδομένων. Το πρόβλημα είναι: πόσος χρόνος χρειάζεται για να δημιουργηθεί μια βασική εικόνα; Και πόσος χρόνος χρειάζεται για να αναπτυχθεί στο επιθυμητό περιβάλλον;
Καταλήξαμε σε ένα σχήμα: εάν ο πελάτης έχει ένα σταθερό σύνολο δεδομένων (ελάχιστη έκδοση της βάσης δεδομένων), τότε τα χρησιμοποιούμε από προεπιλογή. Αν μιλάμε για περιβάλλοντα αναθεώρησης, όταν δημιουργήσαμε ένα υποκατάστημα, αναπτύξαμε μια παρουσία της εφαρμογής - ανοίγουμε μια μικρή βάση δεδομένων εκεί. Αλλά βγήκε καλά , όταν παίρνουμε ένα dump από την παραγωγή μία φορά την ημέρα (τη νύχτα) και χτίζουμε ένα κοντέινερ Docker με PostgreSQL και MySQL με αυτά τα φορτωμένα δεδομένα που βασίζονται σε αυτό. Εάν χρειάζεται να επεκτείνετε τη βάση δεδομένων 50 φορές από αυτήν την εικόνα, αυτό γίνεται πολύ απλά και γρήγορα.
NS: Με απλή αντιγραφή;
DS: Τα δεδομένα αποθηκεύονται απευθείας στην εικόνα Docker. Εκείνοι. Έχουμε μια έτοιμη εικόνα, αν και 100 GB. Χάρη στα επίπεδα στο Docker, μπορούμε να αναπτύξουμε γρήγορα αυτήν την εικόνα όσες φορές χρειαζόμαστε. Η μέθοδος είναι ανόητη, αλλά λειτουργεί καλά.
NS: Τότε, όταν δοκιμάζετε, αλλάζει ακριβώς μέσα στο Docker, σωστά; Αντιγραφή σε εγγραφή στο Docker - πετάξτε το και πηγαίνετε ξανά, όλα είναι καλά. Τάξη! Και το χρησιμοποιείτε ήδη στο έπακρο;
DS: Για πολύ καιρό.
NS: Κάνουμε πολύ παρόμοια πράγματα. Μόνο που δεν χρησιμοποιούμε το copy-on-write του Docker, αλλά κάποιο άλλο.
DS: Δεν είναι γενικό. Και ο Docker λειτουργεί παντού.
NS: Θεωρητικά, ναι. Αλλά έχουμε επίσης ενότητες εκεί, μπορείτε να φτιάξετε διαφορετικές ενότητες και να εργαστείτε με διαφορετικά συστήματα αρχείων. Τι στιγμή εδώ. Από την πλευρά της Postgres, τα βλέπουμε όλα αυτά διαφορετικά. Τώρα κοίταξα από την πλευρά του Docker και είδα ότι όλα λειτουργούν για εσάς. Αλλά αν η βάση δεδομένων είναι τεράστια, για παράδειγμα, 1 TB, τότε όλα αυτά χρειάζονται πολύ χρόνο: λειτουργίες τη νύχτα και γεμίζοντας τα πάντα στο Docker... Και αν 5 TB είναι γεμισμένα στο Docker... Ή είναι όλα καλά;
DS: Ποια είναι η διαφορά: αυτά είναι σταγόνες, απλά bits και byte.
NS: Η διαφορά είναι η εξής: το κάνετε μέσω dump και restore;
DS: Καθόλου απαραίτητο. Οι μέθοδοι για τη δημιουργία αυτής της εικόνας μπορεί να είναι διαφορετικές.
NS: Για ορισμένους πελάτες, το κάναμε έτσι ώστε αντί να δημιουργούμε τακτικά μια βασική εικόνα, τη διατηρούμε συνεχώς ενημερωμένη. Είναι ουσιαστικά ένα αντίγραφο, αλλά λαμβάνει δεδομένα όχι απευθείας από τον κύριο, αλλά μέσω αρχείου. Ένα δυαδικό αρχείο όπου γίνεται λήψη των WAL κάθε μέρα, όπου λαμβάνονται αντίγραφα ασφαλείας... Αυτά τα WAL στη συνέχεια φτάνουν στη βασική εικόνα με μια μικρή καθυστέρηση (κυριολεκτικά 1-2 δευτερόλεπτα). Κλωνοποιούμε από αυτό με οποιονδήποτε τρόπο - τώρα έχουμε το ZFS από προεπιλογή.
DS: Αλλά με το ZFS περιορίζεστε σε έναν κόμβο.
NS: Ναί. Το ZFS όμως έχει και ένα μαγικό : με αυτό μπορείτε να στείλετε ένα στιγμιότυπο και ακόμη (δεν το έχω δοκιμάσει ακόμα, αλλά...) μπορείτε να στείλετε ένα δέλτα μεταξύ δύο PGDATA. Στην πραγματικότητα, έχουμε ένα άλλο εργαλείο που δεν έχουμε σκεφτεί πραγματικά για τέτοιες εργασίες. Η PostgreSQL έχει , που λειτουργεί σαν «έξυπνος» συγχρονισμός, παραλείποντας πολλά από αυτά που δεν χρειάζεται να παρακολουθήσετε, επειδή τίποτα δεν έχει αλλάξει εκεί. Μπορούμε να κάνουμε έναν γρήγορο συγχρονισμό μεταξύ των δύο διακομιστών και να κάνουμε επαναφορά με τον ίδιο τρόπο.
Έτσι, από αυτήν την, πιο DBA πλευρά, προσπαθούμε να δημιουργήσουμε ένα εργαλείο που μας επιτρέπει να κάνουμε το ίδιο πράγμα που είπατε: έχουμε μία βάση δεδομένων, αλλά θέλουμε να δοκιμάσουμε κάτι 50 φορές, σχεδόν ταυτόχρονα.
DS: 50 φορές σημαίνει ότι πρέπει να παραγγείλετε 50 περιπτώσεις Spot.
NS: Όχι, τα κάνουμε όλα σε ένα μηχάνημα.
DS: Αλλά πώς θα επεκτείνετε 50 φορές εάν αυτή η μία βάση δεδομένων είναι, ας πούμε, terabyte. Πιθανότατα χρειάζεται 256 GB μνήμης RAM υπό όρους;
NS: Ναι, μερικές φορές χρειάζεστε πολλή μνήμη - αυτό είναι φυσιολογικό. Αλλά αυτό είναι ένα παράδειγμα από τη ζωή. Η μηχανή παραγωγής έχει 96 πυρήνες και 600 GB. Ταυτόχρονα, 32 πυρήνες (ακόμα και 16 πυρήνες τώρα μερικές φορές) και 100-120 GB μνήμης χρησιμοποιούνται για τη βάση δεδομένων.
DS: Και 50 αντίτυπα χωράνε εκεί μέσα;
NS: Άρα υπάρχει μόνο ένα αντίγραφο, μετά λειτουργεί το copy-on-write (ZFS)... Θα σας πω πιο αναλυτικά.
Για παράδειγμα, έχουμε μια βάση δεδομένων 10 TB. Έφτιαξαν έναν δίσκο για αυτό, το ZFS συμπίεσε επίσης το μέγεθός του κατά 30-40 τοις εκατό. Εφόσον δεν κάνουμε δοκιμή φόρτωσης, ο ακριβής χρόνος απόκρισης δεν είναι σημαντικός για εμάς: ας είναι έως και 2 φορές πιο αργός - δεν πειράζει.
Δίνουμε την ευκαιρία σε προγραμματιστές, QA, DBA κ.λπ. εκτελέστε δοκιμές σε 1-2 νήματα. Για παράδειγμα, μπορεί να εκτελέσουν κάποιο είδος μετανάστευσης. Δεν απαιτεί 10 πυρήνες ταυτόχρονα - χρειάζεται 1 Backend Postgres, 1 πυρήνα. Η μετανάστευση θα ξεκινήσει - ίσως θα συνεχίσει να ξεκινά, τότε θα χρησιμοποιηθεί ο δεύτερος πυρήνας. Διαθέτουμε 16-32 πυρήνες, επομένως 10 άτομα μπορούν να εργάζονται ταυτόχρονα, χωρίς πρόβλημα.
Γιατί σωματικά PGDATA το ίδιο, αποδεικνύεται ότι στην πραγματικότητα εξαπατάμε την Postgres. Το κόλπο είναι το εξής: για παράδειγμα, 10 Postgre εκκινούνται ταυτόχρονα. Ποιο είναι το πρόβλημα συνήθως; Εβαλαν , ας πούμε 25%. Κατά συνέπεια, αυτό είναι 200 GB. Δεν θα μπορείτε να εκκινήσετε περισσότερα από τρία από αυτά, επειδή η μνήμη θα εξαντληθεί.
Αλλά κάποια στιγμή συνειδητοποιήσαμε ότι αυτό δεν ήταν απαραίτητο: ορίσαμε τα shared_buffers στα 2 GB. Η PostgreSQL έχει , και στην πραγματικότητα είναι το μόνο που επηρεάζει . Το ρυθμίσαμε στα 0,5 TB. Και δεν έχει καν σημασία που δεν υπάρχουν στην πραγματικότητα: κάνει σχέδια σαν να υπάρχουν.
Αντίστοιχα, όταν δοκιμάζουμε κάποιο είδος μετανάστευσης, μπορούμε να συλλέξουμε όλα τα σχέδια - θα δούμε πώς θα συμβεί στην παραγωγή. Τα δευτερόλεπτα εκεί θα είναι διαφορετικά (πιο αργά), αλλά τα δεδομένα που πραγματικά διαβάζουμε και τα ίδια τα σχέδια (τι JOIN υπάρχουν κ.λπ.) αποδεικνύονται ακριβώς τα ίδια όπως στην παραγωγή. Και μπορείτε να εκτελέσετε πολλούς τέτοιους ελέγχους παράλληλα σε ένα μηχάνημα.
DS: Δεν νομίζετε ότι υπάρχουν μερικά προβλήματα εδώ; Η πρώτη είναι μια λύση που λειτουργεί μόνο σε PostgreSQL. Αυτή η προσέγγιση είναι πολύ ιδιωτική, δεν είναι γενική. Το δεύτερο είναι ότι το Kubernetes (και όλα όσα πρόκειται να κάνουν τώρα οι τεχνολογίες cloud) περιλαμβάνει πολλούς κόμβους και αυτοί οι κόμβοι είναι εφήμεροι. Και στην περίπτωσή σας είναι ένας κρατικός, επίμονος κόμβος. Αυτά τα πράγματα με φέρνουν σε σύγκρουση.
NS: Πρώτον, συμφωνώ, αυτή είναι μια καθαρά ιστορία Postgres. Νομίζω ότι αν έχουμε κάποιο είδος άμεσης IO και ένα buffer pool για σχεδόν όλη τη μνήμη, αυτή η προσέγγιση δεν θα λειτουργήσει - τα σχέδια θα είναι διαφορετικά. Αλλά προς το παρόν δουλεύουμε μόνο με την Postgres, δεν σκεφτόμαστε άλλους.
Σχετικά με την Kubernetes. Εσείς οι ίδιοι μας λέτε παντού ότι έχουμε μια επίμονη βάση δεδομένων. Εάν η εμφάνιση αποτύχει, το κύριο πράγμα είναι να αποθηκεύσετε το δίσκο. Εδώ έχουμε επίσης ολόκληρη την πλατφόρμα στο Kubernetes και το στοιχείο με το Postgres είναι ξεχωριστό (αν και θα είναι εκεί μια μέρα). Επομένως, όλα είναι έτσι: το στιγμιότυπο έπεσε, αλλά αποθηκεύσαμε το φωτοβολταϊκό του και απλά το συνδέσαμε σε μια άλλη (νέα) παρουσία, σαν να μην είχε συμβεί τίποτα.
DS: Από την άποψή μου, δημιουργούμε pods στο Kubernetes. K8s - ελαστικό: παραγγέλλονται κόμποι ανάλογα με τις ανάγκες. Το καθήκον είναι απλώς να δημιουργήσετε ένα pod και να πείτε ότι χρειάζεται X ποσότητα πόρων και μετά το K8s θα το καταλάβει μόνο του. Αλλά η υποστήριξη αποθήκευσης στο Kubernetes εξακολουθεί να είναι ασταθής: Σε (αυτή η έκδοση κυκλοφόρησε της εβδομάδας πριν) αυτά τα χαρακτηριστικά έγιναν μόνο beta.
Θα περάσουν έξι μήνες με έναν χρόνο - θα γίνει λίγο πολύ σταθερό ή τουλάχιστον θα δηλωθεί ως τέτοιο. Στη συνέχεια, η δυνατότητα λήψης στιγμιότυπων και αλλαγής μεγέθους λύνει πλήρως το πρόβλημά σας. Γιατί έχεις βάση. Ναι, μπορεί να μην είναι πολύ γρήγορο, αλλά η ταχύτητα εξαρτάται από το τι βρίσκεται "κάτω από την κουκούλα", επειδή ορισμένες υλοποιήσεις μπορούν να αντιγράψουν και να αντιγράψουν σε εγγραφή σε επίπεδο υποσυστήματος δίσκου.
NS: Είναι επίσης απαραίτητο όλοι οι κινητήρες (Amazon, Google...) να αρχίσουν να υποστηρίζουν αυτήν την έκδοση - αυτό απαιτεί επίσης λίγο χρόνο.
DS: Δεν τα χρησιμοποιούμε ακόμα. Χρησιμοποιούμε το δικό μας.
Τοπική ανάπτυξη για την Kubernetes
NS: Έχετε συναντήσει μια τέτοια επιθυμία όταν πρέπει να εγκαταστήσετε όλα τα pods σε ένα μηχάνημα και να κάνετε μια τόσο μικρή δοκιμή. Για να αποκτήσετε γρήγορα μια απόδειξη της ιδέας, δείτε ότι η εφαρμογή εκτελείται στο Kubernetes, χωρίς να της αφιερώσετε ένα σωρό μηχανήματα. Υπάρχει το Minikube, σωστά;
DS: Μου φαίνεται ότι αυτή η υπόθεση - που αναπτύσσεται σε έναν κόμβο - αφορά αποκλειστικά την τοπική ανάπτυξη. Ή κάποιες εκδηλώσεις ενός τέτοιου μοτίβου. Τρώω , Υπάρχει , . Προχωράμε προς τη χρήση του Kubernetes IN Docker. Τώρα αρχίσαμε να δουλεύουμε με αυτό για δοκιμές.
NS: Πίστευα ότι αυτή ήταν μια προσπάθεια να τυλίξουμε όλα τα pods σε μια εικόνα Docker. Αλλά αποδείχθηκε ότι πρόκειται για κάτι εντελώς διαφορετικό. Εν πάση περιπτώσει, υπάρχουν ξεχωριστά δοχεία, ξεχωριστοί λοβοί - μόνο στο Docker.
DS: Ναί. Και υπάρχει μια μάλλον αστεία απομίμηση, αλλά το νόημα είναι αυτό... Έχουμε ένα βοηθητικό πρόγραμμα για την ανάπτυξη - . Θέλουμε να το κάνουμε λειτουργία υπό όρους werf up: "Πάρτε μου τοπικά Kubernetes." Και μετά εκτελέστε το υπό όρους εκεί werf follow. Στη συνέχεια, ο προγραμματιστής θα μπορεί να επεξεργαστεί το IDE και θα ξεκινήσει μια διαδικασία στο σύστημα που βλέπει τις αλλαγές και αναδομεί τις εικόνες, επανατοποθετώντας τις σε τοπικά K8. Έτσι θέλουμε να προσπαθήσουμε να λύσουμε το πρόβλημα της τοπικής ανάπτυξης.
Στιγμιότυπα και κλωνοποίηση βάσεων δεδομένων στο reality K8s
NS: Εάν επιστρέψουμε στην αντιγραφή σε εγγραφή. Παρατήρησα ότι τα σύννεφα έχουν και στιγμιότυπα. Λειτουργούν διαφορετικά. Για παράδειγμα, στο GCP: έχετε μια παρουσία πολλών terabyte στην ανατολική ακτή των Ηνωμένων Πολιτειών. Τραβάτε στιγμιότυπα περιοδικά. Παίρνετε ένα αντίγραφο του δίσκου στη δυτική ακτή από ένα στιγμιότυπο - σε λίγα λεπτά όλα είναι έτοιμα, λειτουργεί πολύ γρήγορα, μόνο η μνήμη cache χρειάζεται να γεμίσει στη μνήμη. Αλλά αυτοί οι κλώνοι (στιγμιότυπα) είναι για να «παρέχουν» έναν νέο τόμο. Αυτό είναι ωραίο όταν χρειάζεται να δημιουργήσετε πολλές περιπτώσεις.
Αλλά για δοκιμές, μου φαίνεται ότι τα στιγμιότυπα, για τα οποία μιλάτε στο Docker ή εγώ στο ZFS, btrfs ακόμα και LVM... - σας επιτρέπουν να μην δημιουργείτε πραγματικά νέα δεδομένα σε ένα μηχάνημα. Στο cloud, θα εξακολουθείτε να πληρώνετε για αυτά κάθε φορά και να περιμένετε όχι δευτερόλεπτα, αλλά λεπτά (και στην περίπτωση , πιθανώς ένα ρολόι).
Αντίθετα, μπορείτε να λάβετε αυτά τα δεδομένα σε ένα ή δύο δευτερόλεπτα, να εκτελέσετε τη δοκιμή και να τα πετάξετε. Αυτά τα στιγμιότυπα λύνουν διάφορα προβλήματα. Στην πρώτη περίπτωση - για κλιμάκωση και λήψη νέων αντιγράφων, και στη δεύτερη - για δοκιμές.
DS: Δεν συμφωνώ. Η σωστή λειτουργία της κλωνοποίησης τόμου είναι καθήκον του cloud. Δεν έχω κοιτάξει την εφαρμογή τους, αλλά ξέρω πώς το κάνουμε σε υλικό. Έχουμε Ceph, επιτρέπει οποιονδήποτε φυσικό όγκο () λένε κλωνοποίηση και πάρτε έναν δεύτερο τόμο με τα ίδια χαρακτηριστικά σε δεκάδες χιλιοστά του δευτερολέπτου, 'αμί, κλπ. Πρέπει να καταλάβετε ότι υπάρχει ένα δύσκολο αντίγραφο σε εγγραφή μέσα. Γιατί να μην κάνει το ίδιο το σύννεφο; Είμαι σίγουρος ότι προσπαθούν να το κάνουν με τον έναν ή τον άλλον τρόπο.
NS: Αλλά θα χρειαστούν ακόμη δευτερόλεπτα, δεκάδες δευτερόλεπτα για να δημιουργήσουν ένα παράδειγμα, να φέρουν τον Docker εκεί κ.λπ.
DS: Γιατί είναι απαραίτητο να σηκωθεί ένα ολόκληρο παράδειγμα; Έχουμε ένα παράδειγμα με 32 πυρήνες, 16... και μπορεί να χωρέσει σε αυτό - για παράδειγμα, τέσσερις. Όταν παραγγείλουμε το πέμπτο, η παρουσία θα έχει ήδη ανέβει και στη συνέχεια θα διαγραφεί.
NS: Ναι, ενδιαφέρον, το Kubernetes αποδεικνύεται μια διαφορετική ιστορία. Η βάση δεδομένων μας δεν είναι σε K8, και έχουμε ένα παράδειγμα. Αλλά η κλωνοποίηση μιας βάσης δεδομένων πολλών terabyte δεν διαρκεί περισσότερο από δύο δευτερόλεπτα.
DS: Αυτό είναι υπέροχο. Αλλά το αρχικό μου σημείο είναι ότι αυτή δεν είναι μια γενική λύση. Ναι, είναι ωραίο, αλλά είναι κατάλληλο μόνο για Postgres και μόνο σε έναν κόμβο.
NS: Είναι κατάλληλο όχι μόνο για την Postgres: αυτά τα σχέδια, όπως περιέγραψα, θα λειτουργήσουν μόνο σε αυτό. Αλλά αν δεν ασχολούμαστε με τα σχέδια και χρειαζόμαστε απλώς όλα τα δεδομένα για λειτουργικές δοκιμές, τότε αυτό είναι κατάλληλο για οποιοδήποτε DBMS.
DS: Πριν από πολλά χρόνια κάναμε κάτι παρόμοιο σε στιγμιότυπα LVM. Αυτό είναι ένα κλασικό. Αυτή η προσέγγιση χρησιμοποιήθηκε πολύ ενεργά. Οι κρατικοί κόμβοι είναι απλώς ένας πόνος. Γιατί δεν πρέπει να τα ρίχνεις, πρέπει πάντα να τα θυμάσαι...
NS: Βλέπετε κάποια πιθανότητα υβριδικού εδώ; Ας πούμε ότι το stateful είναι κάποιο είδος pod, λειτουργεί για πολλά άτομα (πολλούς δοκιμαστές). Έχουμε έναν τόμο, αλλά χάρη στο σύστημα αρχείων, οι κλώνοι είναι τοπικοί. Εάν το pod πέσει, αλλά ο δίσκος παραμείνει, το pod θα σηκωθεί, θα μετρήσει πληροφορίες για όλους τους κλώνους, θα ξαναπάρει τα πάντα και θα πει: "Εδώ είναι οι κλώνοι σας που τρέχουν σε αυτές τις θύρες, συνεχίστε να εργάζεστε μαζί τους."
DS: Τεχνικά αυτό σημαίνει ότι μέσα στο Kubernetes είναι ένα pod μέσα στο οποίο τρέχουμε πολλά Postgres.
NS: Ναί. Έχει ένα όριο: ας πούμε ότι δεν εργάζονται μαζί του περισσότερα από 10 άτομα ταυτόχρονα. Εάν χρειάζεστε 20, θα ξεκινήσουμε ένα δεύτερο τέτοιο pod. Θα το κλωνοποιήσουμε πλήρως, έχοντας λάβει τον δεύτερο πλήρη τόμο, θα έχει τους ίδιους 10 «λεπτούς» κλώνους. Δεν βλέπετε αυτή την ευκαιρία;
DS: Πρέπει να προσθέσουμε ζητήματα ασφαλείας εδώ. Αυτός ο τύπος οργάνωσης υποδηλώνει ότι αυτό το pod έχει υψηλά προνόμια (δυνατότητες), επειδή μπορεί να εκτελέσει μη τυπικές λειτουργίες στο σύστημα αρχείων... Αλλά επαναλαμβάνω: πιστεύω ότι μεσοπρόθεσμα θα διορθώσουν την αποθήκευση στο Kubernetes και στο τα σύννεφα θα φτιάξουν όλη την ιστορία με τόμους - όλα θα «απλώς λειτουργήσουν». Θα υπάρξει αλλαγή μεγέθους, κλωνοποίηση... Υπάρχει ένας τόμος - λέμε: «Δημιουργήστε ένα νέο με βάση αυτό», και μετά από ενάμιση δευτερόλεπτο παίρνουμε αυτό που χρειαζόμαστε.
NS: Δεν πιστεύω σε ενάμιση δευτερόλεπτο για πολλά terabyte. Στο Ceph το κάνεις μόνος σου, αλλά μιλάς για τα σύννεφα. Πηγαίνετε στο cloud, κάντε έναν κλώνο ενός τόμου EBS πολλών terabyte στο EC2 και δείτε ποια θα είναι η απόδοση. Δεν θα πάρει μερικά δευτερόλεπτα. Με ενδιαφέρει πολύ πότε θα φτάσουν σε αυτό το επίπεδο. Καταλαβαίνω τι λες, αλλά παρακαλώ να διαφέρω.
DS: Εντάξει, αλλά είπα μεσοπρόθεσμα, όχι βραχυπρόθεσμα. Για πολλά χρόνια.
Σχετικά με τον τελεστή για PostgreSQL από το Zalando
Στη μέση αυτής της συνάντησης, ο Alexey Klyukin, ένας πρώην προγραμματιστής από το Zalando, συμμετείχε επίσης και μίλησε για την ιστορία του χειριστή PostgreSQL:
Είναι υπέροχο που αυτό το θέμα θίγεται γενικά: τόσο η Postgres όσο και η Kubernetes. Όταν ξεκινήσαμε να το κάνουμε στο Zalando το 2017, ήταν ένα θέμα που όλοι ήθελαν να κάνουν, αλλά κανείς δεν το έκανε. Όλοι είχαν ήδη Kubernetes, αλλά όταν ρώτησαν τι να κάνουν με τις βάσεις δεδομένων, αρέσει ακόμη και στους ανθρώπους , που κήρυττε τα K8, είπε κάτι σαν αυτό:
«Μεταβείτε σε διαχειριζόμενες υπηρεσίες και χρησιμοποιήστε τις, μην εκτελείτε τη βάση δεδομένων στο Kubernetes. Διαφορετικά, τα K8 σας θα αποφασίσουν, για παράδειγμα, να κάνουν μια αναβάθμιση, να απενεργοποιήσουν όλους τους κόμβους και τα δεδομένα σας θα πετάξουν πολύ, πολύ μακριά.»
Αποφασίσαμε να δημιουργήσουμε έναν χειριστή που, σε αντίθεση με αυτήν τη συμβουλή, θα ξεκινήσει μια βάση δεδομένων Postgres στο Kubernetes. Και είχαμε έναν καλό λόγο - . Αυτό είναι ένα αυτόματο failover για την PostgreSQL, που έγινε σωστά, π.χ. χρησιμοποιώντας etcd, consul ή ZooKeeper ως αποθήκευση πληροφοριών σχετικά με το σύμπλεγμα. Ένα τέτοιο αποθετήριο που θα δίνει σε όποιον ρωτάει, για παράδειγμα, ποιος είναι ο σημερινός αρχηγός, τις ίδιες πληροφορίες -παρά το γεγονός ότι τα έχουμε όλα μοιρασμένα- ώστε να μην υπάρχει διχασμός εγκεφάλου. Επιπλέον είχαμε για αυτόν.
Γενικά, η ανάγκη της εταιρείας για αυτόματη ανακατεύθυνση εμφανίστηκε μετά τη μετάβαση από ένα εσωτερικό κέντρο δεδομένων υλικού στο cloud. Το cloud βασίστηκε σε μια αποκλειστική λύση PaaS (Platform-as-a-Service). Είναι Ανοιχτού Κώδικα, αλλά χρειάστηκε πολλή δουλειά για να τεθεί σε λειτουργία. λεγόταν .
Αρχικά, δεν υπήρχε Kubernetes. Πιο συγκεκριμένα, όταν αναπτύχθηκε η δική μας λύση, τα K8 υπήρχαν ήδη, αλλά ήταν τόσο ακατέργαστα που δεν ήταν κατάλληλα για παραγωγή. Ήταν, κατά τη γνώμη μου, το 2015 ή το 2016. Μέχρι το 2017, το Kubernetes είχε γίνει περισσότερο ή λιγότερο ώριμο - υπήρχε ανάγκη να μεταναστεύσουν εκεί.
Και είχαμε ήδη ένα κοντέινερ Docker. Υπήρχε ένα PaaS που χρησιμοποιούσε Docker. Γιατί να μην δοκιμάσετε τα K8; Γιατί να μην γράψετε τον δικό σας χειριστή; Ο Murat Kabilov, ο οποίος ήρθε σε εμάς από το Avito, το ξεκίνησε ως έργο με δική του πρωτοβουλία - "να παίξει" - και το έργο "απογειώθηκε".
Αλλά γενικά, ήθελα να μιλήσω για το AWS. Γιατί υπήρχε ιστορικός κώδικας που σχετίζεται με το AWS...
Όταν εκτελείτε κάτι στο Kubernetes, πρέπει να καταλάβετε ότι το K8s είναι ένα τέτοιο έργο σε εξέλιξη. Αναπτύσσεται συνεχώς, βελτιώνεται, ακόμη και καταρρέει από καιρό σε καιρό. Πρέπει να παρακολουθείτε στενά όλες τις αλλαγές στο Kubernetes, πρέπει να είστε έτοιμοι να το βουτήξετε αν συμβεί κάτι και να μάθετε πώς λειτουργεί λεπτομερώς - ίσως περισσότερο από όσο θα θέλατε. Αυτό, καταρχήν, ισχύει για οποιαδήποτε πλατφόρμα στην οποία εκτελείτε τις βάσεις δεδομένων σας...
Έτσι, όταν κάναμε τη δήλωση, είχαμε το Postgres να τρέχει σε εξωτερικό τόμο (EBS σε αυτήν την περίπτωση, αφού εργαζόμασταν σε AWS). Η βάση δεδομένων μεγάλωσε, κάποια στιγμή χρειάστηκε να αλλάξει το μέγεθός της: για παράδειγμα, το αρχικό μέγεθος του EBS ήταν 100 TB, η βάση δεδομένων αυξήθηκε σε αυτό, τώρα θέλουμε να κάνουμε EBS 200 TB. Πως? Ας υποθέσουμε ότι μπορείτε να κάνετε μια απόθεση/επαναφορά σε μια νέα παρουσία, αλλά αυτό θα διαρκέσει πολύ και θα συνεπάγεται χρόνο διακοπής λειτουργίας.
Επομένως, ήθελα μια αλλαγή μεγέθους που θα μεγεθύνει το διαμέρισμα EBS και στη συνέχεια θα έλεγε στο σύστημα αρχείων να χρησιμοποιήσει το νέο χώρο. Και το κάναμε, αλλά εκείνη την εποχή η Kubernetes δεν είχε κανένα API για τη λειτουργία αλλαγής μεγέθους. Εφόσον δουλέψαμε στο AWS, γράψαμε κώδικα για το API του.
Κανείς δεν σας εμποδίζει να κάνετε το ίδιο για άλλες πλατφόρμες. Δεν υπάρχει υπόδειξη στη δήλωση ότι μπορεί να εκτελεστεί μόνο σε AWS και δεν θα λειτουργήσει σε οτιδήποτε άλλο. Σε γενικές γραμμές, αυτό είναι ένα έργο ανοιχτού κώδικα: αν κάποιος θέλει να επιταχύνει την εμφάνιση της χρήσης του νέου API, είστε ευπρόσδεκτοι. Τρώω , pull αιτήματα - η ομάδα Zalando προσπαθεί να ανταποκριθεί σε αυτά αρκετά γρήγορα και να προωθήσει τον χειριστή. Από όσο γνωρίζω, το έργο στο Google Summer of Code και σε κάποιες άλλες παρόμοιες πρωτοβουλίες. Ο Zalando εργάζεται πολύ ενεργά σε αυτό.
PS Bonus!
Εάν ενδιαφέρεστε για το θέμα PostgreSQL και Kubernetes, τότε παρακαλώ σημειώστε επίσης ότι η επόμενη Postgres Τρίτη πραγματοποιήθηκε την περασμένη εβδομάδα, όπου μίλησα με τον Nikolai Alexander Kukushkin από Zalando. Βίντεο από αυτό είναι διαθέσιμο .
ΜΑΔ
Διαβάστε επίσης στο blog μας:
- «"?
- «"?
- «"?
- «».
Πηγή: www.habr.com