Γεια σε όλους, με λένε Sergey Emelyanchik. Είμαι επικεφαλής της εταιρείας Audit-Telecom, ο κύριος προγραμματιστής και συγγραφέας του συστήματος Veliam. Αποφάσισα να γράψω ένα άρθρο για το πώς ο φίλος μου και εγώ δημιουργήσαμε μια εταιρεία outsourcing, γράψαμε λογισμικό για εμάς και στη συνέχεια άρχισα να το διανέμουμε σε όλους μέσω του συστήματος SaaS. Για το πώς κατηγορηματικά δεν πίστευα ότι αυτό ήταν δυνατό. Το άρθρο θα περιέχει όχι μόνο μια ιστορία, αλλά και τεχνικές λεπτομέρειες για το πώς δημιουργήθηκε το προϊόν Veliam. Συμπεριλαμβανομένων ορισμένων κομματιών πηγαίου κώδικα. Θα σας πω ποια λάθη κάναμε και πώς τα διορθώσαμε αργότερα. Υπήρχαν αμφιβολίες για τη δημοσίευση ενός τέτοιου άρθρου. Αλλά σκέφτηκα ότι ήταν καλύτερο να το κάνω, να λάβω σχόλια και να βελτιωθώ, παρά να μην δημοσιεύσω το άρθρο και να σκεφτώ τι θα είχε συμβεί αν...
Ιστορικό
Εργάστηκα σε μια εταιρεία ως υπάλληλος πληροφορικής. Η εταιρεία ήταν αρκετά μεγάλη με εκτεταμένη δομή δικτύου. Δεν θα σταθώ στις εργασιακές μου ευθύνες, θα πω μόνο ότι σίγουρα δεν περιλάμβαναν την εξέλιξη τίποτα.
Είχαμε παρακολούθηση, αλλά καθαρά από ακαδημαϊκό ενδιαφέρον ήθελα να προσπαθήσω να γράψω το δικό μου πιο απλό. Η ιδέα ήταν η εξής: ήθελα να είναι στον ιστό, ώστε να μπορώ εύκολα να μπω χωρίς να εγκαταστήσω κανένα πελάτη και να δω τι συνέβαινε με το δίκτυο από οποιαδήποτε συσκευή, συμπεριλαμβανομένης μιας κινητής συσκευής μέσω Wi-Fi, και επίσης πραγματικά Ήθελε να καταλάβει γρήγορα τι Υπάρχει εξοπλισμός στο δωμάτιο που έχει γίνει "μουπαϊκός" επειδή... Υπήρχαν πολύ αυστηρές απαιτήσεις για τον χρόνο απόκρισης σε τέτοια προβλήματα. Ως αποτέλεσμα, γεννήθηκε ένα σχέδιο στο μυαλό μου να γράψω μια απλή ιστοσελίδα στην οποία υπήρχε ένα φόντο jpeg με ένα διάγραμμα δικτύου, να κόψω τις ίδιες τις συσκευές με τις διευθύνσεις IP τους σε αυτήν την εικόνα και να εμφανίσω δυναμικό περιεχόμενο πάνω από το εικόνα στις απαιτούμενες συντεταγμένες με τη μορφή πράσινης ή κόκκινης διεύθυνσης IP που αναβοσβήνει. Η εργασία έχει τεθεί, ας ξεκινήσουμε.
Προηγουμένως, προγραμματιζόμουν σε Delphi, PHP, JS και πολύ επιφανειακά σε C++. Ξέρω πολύ καλά πώς λειτουργούν τα δίκτυα. VLAN, Δρομολόγηση (OSPF, EIGRP, BGP), NAT. Αυτό ήταν αρκετό για να γράψω μόνος μου ένα πρωτόγονο πρωτότυπο παρακολούθησης.
Έγραψα αυτό που σχεδίαζα στην PHP. Ο διακομιστής Apache και PHP ήταν στα Windows επειδή... Το Linux για μένα εκείνη τη στιγμή ήταν κάτι ακατανόητο και πολύ περίπλοκο, όπως αποδείχθηκε αργότερα, έκανα πολύ λάθος και σε πολλά σημεία το Linux είναι πολύ πιο απλό από τα Windows, αλλά αυτό είναι ένα ξεχωριστό θέμα και όλοι ξέρουμε πόσα holivar υπάρχουν στο αυτό το θέμα. Ο προγραμματιστής εργασιών των Windows τράβηξε σε ένα μικρό διάστημα (δεν θυμάμαι ακριβώς, αλλά κάτι σαν μία φορά κάθε τρία δευτερόλεπτα) ένα σενάριο PHP που μετρούσε όλα τα αντικείμενα με ένα κοινόχρηστο ping και αποθήκευε την κατάσταση σε ένα αρχείο.
system(“ping -n 3 -w 100 {$ip_address}“);
Ναι, ναι, η εργασία με μια βάση δεδομένων εκείνη τη στιγμή δεν ήταν επίσης κατακτημένη για μένα. Δεν ήξερα ότι ήταν δυνατός ο παραλληλισμός των διαδικασιών και η διέλευση από όλους τους κόμβους του δικτύου χρειάστηκε πολύ χρόνο, γιατί... αυτό συνέβη σε ένα νήμα. Προβλήματα προέκυψαν ιδιαίτερα όταν αρκετοί κόμβοι δεν ήταν διαθέσιμοι, επειδή καθένας από αυτούς καθυστέρησε το σενάριο για 300 ms. Στην πλευρά του πελάτη υπήρχε μια απλή λειτουργία βρόχου που, σε διαστήματα μερικών δευτερολέπτων, κατέβαζε ενημερωμένες πληροφορίες από τον διακομιστή με αίτημα Ajax και ενημερωνόταν η διεπαφή. Λοιπόν, μετά από 3 ανεπιτυχή ping στη σειρά, αν μια ιστοσελίδα με παρακολούθηση ήταν ανοιχτή στον υπολογιστή, έπαιζε μια χαρούμενη σύνθεση.
Όταν όλα λειτούργησαν, εμπνεύστηκα πολύ από το αποτέλεσμα και σκέφτηκα ότι θα μπορούσα να προσθέσω περισσότερα σε αυτό (λόγω των γνώσεων και των δυνατοτήτων μου). Αλλά πάντα δεν μου άρεσαν τα συστήματα με ένα εκατομμύριο γραφήματα, τα οποία πίστευα ότι τότε, και εξακολουθώ να πιστεύω μέχρι σήμερα, είναι περιττά στις περισσότερες περιπτώσεις. Ήθελα να βάλω εκεί μόνο ό,τι θα με βοηθούσε πραγματικά στη δουλειά μου. Αυτή η αρχή παραμένει θεμελιώδης για την ανάπτυξη του Veliam μέχρι σήμερα. Επιπλέον, συνειδητοποίησα ότι θα ήταν πολύ ωραίο αν δεν χρειαζόταν να συνεχίσω να παρακολουθώ ανοιχτή και να γνωρίζω τα προβλήματα, και όταν συνέβη, ανοίξτε τη σελίδα και δείτε πού βρίσκεται αυτός ο προβληματικός κόμβος δικτύου και τι να τον κάνω στη συνέχεια . Κατά κάποιο τρόπο δεν διάβασα το email τότε, απλά δεν το χρησιμοποίησα. Συνάντησα στο Διαδίκτυο ότι υπάρχουν πύλες SMS στις οποίες μπορείτε να στείλετε αίτημα GET ή POST και θα στείλουν ένα SMS στο κινητό μου τηλέφωνο με το κείμενο που γράφω. Αμέσως κατάλαβα ότι το ήθελα πολύ αυτό. Και άρχισα να μελετώ την τεκμηρίωση. Μετά από αρκετό καιρό τα κατάφερα και τώρα έλαβα ένα SMS για προβλήματα στο δίκτυο στο κινητό μου τηλέφωνο με το όνομα ενός "πεσμένου αντικειμένου". Αν και το σύστημα ήταν πρωτόγονο, γράφτηκε από εμένα ο ίδιος και το πιο σημαντικό πράγμα που με παρακίνησε να το αναπτύξω ήταν ότι ήταν ένα πρόγραμμα εφαρμογής που με βοήθησε πραγματικά στη δουλειά μου.
Και μετά ήρθε η μέρα που ένα από τα κανάλια του Διαδικτύου έπεσε στη δουλειά και η παρακολούθηση δεν με άφησε να το μάθω. Δεδομένου ότι το Google DNS εξακολουθούσε να κάνει ping τέλεια. Ήρθε η ώρα να σκεφτείτε πώς μπορείτε να παρακολουθήσετε ότι το κανάλι επικοινωνίας είναι ζωντανό. Υπήρχαν διαφορετικές ιδέες για το πώς να γίνει αυτό. Δεν είχα πρόσβαση σε όλο τον εξοπλισμό. Έπρεπε να καταλάβουμε πώς να καταλάβουμε ποιο από τα κανάλια είναι ζωντανά, αλλά χωρίς να μπορούμε να το δούμε με κάποιο τρόπο στον ίδιο τον εξοπλισμό δικτύου. Στη συνέχεια, ένας συνάδελφος σκέφτηκε ότι είναι πιθανό η ανίχνευση διαδρομής στους δημόσιους διακομιστές να διαφέρει ανάλογα με το κανάλι επικοινωνίας που χρησιμοποιείται αυτήν τη στιγμή για πρόσβαση στο Διαδίκτυο. Έλεγξα και αποδείχτηκε έτσι. Υπήρχαν διαφορετικές διαδρομές κατά τον εντοπισμό.
system(“tracert -d -w 500 8.8.8.8”);
Έτσι εμφανίστηκε ένα άλλο σενάριο, ή μάλλον, για κάποιο λόγο προστέθηκε το ίχνος στο τέλος του ίδιου σεναρίου, το οποίο έκανε ping σε όλες τις συσκευές στο δίκτυο. Άλλωστε, αυτή είναι μια ακόμη μεγάλη διαδικασία που εκτελέστηκε στο ίδιο νήμα και επιβράδυνε τη δουλειά ολόκληρου του σεναρίου. Αλλά τότε δεν ήταν τόσο προφανές. Αλλά με τον ένα ή τον άλλο τρόπο, έκανε τη δουλειά του, ο κώδικας όριζε αυστηρά τι είδους ιχνηλάτηση θα έπρεπε να είναι για κάθε ένα από τα κανάλια. Έτσι άρχισε να λειτουργεί το σύστημα, το οποίο ήδη παρακολουθούσε (ειπώθηκε δυνατά, επειδή δεν υπήρχε συλλογή μετρήσεων, αλλά απλώς ping) συσκευές δικτύου (δρομολογητές, διακόπτες, wi-fi κ.λπ.) και κανάλια επικοινωνίας με τον έξω κόσμο . Τα μηνύματα SMS έφταναν τακτικά και το διάγραμμα έδειχνε πάντα ξεκάθαρα πού ήταν το πρόβλημα.
Επιπλέον, στην καθημερινή δουλειά έπρεπε να κάνω cross-crossing. Και βαρέθηκα να πηγαίνω στους διακόπτες Cisco κάθε φορά για να δω ποια διεπαφή να χρησιμοποιήσω. Πόσο ωραίο θα ήταν να κάνετε κλικ σε ένα αντικείμενο στην παρακολούθηση και να δείτε μια λίστα με τις διεπαφές του με περιγραφές. Θα μου εξοικονομούσε χρόνο. Επιπλέον, σε αυτό το σχήμα δεν θα χρειαζόταν να εκτελέσετε Putty ή SecureCRT για να εισάγετε λογαριασμούς και εντολές. Απλώς έκανα κλικ στην παρακολούθηση, είδα τι χρειαζόταν και πήγα να κάνω τη δουλειά μου. Άρχισα να ψάχνω τρόπους αλληλεπίδρασης με διακόπτες. Βρήκα αμέσως 2 επιλογές: SNMP ή σύνδεση στο switch μέσω SSH, εισαγωγή των εντολών που χρειαζόμουν και ανάλυση του αποτελέσματος. Απέρριψα το SNMP λόγω της πολυπλοκότητας της εφαρμογής του· ήμουν ανυπόμονος να πάρω το αποτέλεσμα. με το SNMP, θα πρέπει να ψάξετε στο MIB για μεγάλο χρονικό διάστημα και, με βάση αυτά τα δεδομένα, να δημιουργήσετε δεδομένα σχετικά με τις διεπαφές. Υπάρχει μια υπέροχη ομάδα στη CISCO
show interface statusΔείχνει ακριβώς τι χρειάζομαι για διασταυρώσεις. Γιατί να ασχοληθώ με το SNMP όταν θέλω απλώς να δω την έξοδο αυτής της εντολής, σκέφτηκα. Μετά από λίγο, συνειδητοποίησα αυτή την ευκαιρία. Κάντε κλικ σε ένα αντικείμενο σε μια ιστοσελίδα. Ενεργοποιήθηκε ένα συμβάν από το οποίο ο πελάτης AJAX επικοινώνησε με τον διακομιστή και αυτός, με τη σειρά του, συνδέθηκε μέσω SSH στον διακόπτη που χρειαζόμουν (τα διαπιστευτήρια ήταν κωδικοποιημένα στον κώδικα, δεν υπήρχε επιθυμία να τον βελτιώσουμε, να δημιουργήσουμε κάποια ξεχωριστά μενού όπου θα ήταν δυνατή η αλλαγή λογαριασμών από τη διεπαφή , χρειαζόμουν το αποτέλεσμα και γρήγορα) Έβαλα την παραπάνω εντολή εκεί και την έστειλα πίσω στο πρόγραμμα περιήγησης. Άρχισα λοιπόν να βλέπω πληροφορίες για τις διεπαφές με ένα κλικ του ποντικιού. Αυτό ήταν εξαιρετικά βολικό, ειδικά όταν έπρεπε να προβάλετε αυτές τις πληροφορίες σε διαφορετικούς διακόπτες ταυτόχρονα.
Η παρακολούθηση καναλιών που βασίζεται σε ίχνη δεν ήταν η καλύτερη ιδέα, γιατί... μερικές φορές γίνονταν εργασίες στο δίκτυο και η ιχνηλάτηση μπορούσε να αλλάξει και η παρακολούθηση άρχισε να μου φωνάζει ότι υπήρχαν προβλήματα με το κανάλι. Αλλά αφού πέρασα πολύ χρόνο σε αναλύσεις, συνειδητοποίησα ότι όλα τα κανάλια λειτουργούσαν και η παρακολούθηση μου με εξαπατούσε. Ως αποτέλεσμα, ζήτησα από τους συναδέλφους μου που διαχειρίζονταν διακόπτες σχηματισμού καναλιών να μου στείλουν απλώς το syslog όταν άλλαζε η κατάσταση ορατότητας των γειτόνων. Κατά συνέπεια, ήταν πολύ πιο απλό, πιο γρήγορο και ακριβές από τον εντοπισμό. Έφτασε ένα συμβάν όπως ο χαμένος γείτονας και εκδώσω αμέσως μια ειδοποίηση σχετικά με το κανάλι κάτω.
Επιπλέον, εμφανίστηκαν αρκετές ακόμη εντολές όταν κάνετε κλικ σε ένα αντικείμενο και προστέθηκε SNMP για τη συλλογή ορισμένων μετρήσεων, και αυτό είναι βασικά. Το σύστημα δεν αναπτύχθηκε ποτέ περισσότερο. Έκανε ό,τι χρειαζόμουν, ήταν ένα καλό εργαλείο. Πολλοί αναγνώστες θα μου πουν πιθανώς ότι υπάρχει ήδη πολύ λογισμικό στο Διαδίκτυο για την επίλυση αυτών των προβλημάτων. Αλλά στην πραγματικότητα, δεν έψαξα στο google τέτοια δωρεάν προϊόντα τότε και ήθελα πραγματικά να αναπτύξω τις δεξιότητές μου στον προγραμματισμό και τι καλύτερο από ένα πραγματικό πρόβλημα εφαρμογής. Σε αυτό το σημείο, ολοκληρώθηκε η πρώτη έκδοση της παρακολούθησης και δεν τροποποιήθηκε πλέον.
Δημιουργία της εταιρείας Audit-Telecom
Όσο περνούσε ο καιρός, άρχισα να εργάζομαι με μερική απασχόληση σε άλλες εταιρείες, ευτυχώς το πρόγραμμα εργασίας μου το επέτρεψε. Όταν εργάζεστε σε διαφορετικές εταιρείες, οι δεξιότητές σας σε διάφορους τομείς αναπτύσσονται πολύ γρήγορα και οι ορίζοντές σας αναπτύσσονται καλά. Υπάρχουν εταιρείες στις οποίες, όπως λένε, είσαι Σουηδός, θεριστής και τρομπετίστας. Από τη μια είναι δύσκολο, από την άλλη, αν δεν είσαι τεμπέλης, γίνεσαι γενικός και αυτό σου επιτρέπει να λύνεις προβλήματα πιο γρήγορα και πιο αποτελεσματικά γιατί ξέρεις πώς λειτουργεί το σχετικό πεδίο.
Ο φίλος μου Pavel (επίσης ειδικός πληροφορικής) προσπαθούσε συνεχώς να με ενθαρρύνει να ξεκινήσω τη δική του επιχείρηση. Υπήρχαν αμέτρητες ιδέες με διαφορετικές παραλλαγές αυτού που έκαναν. Αυτό συζητείται εδώ και χρόνια. Και στην τελική, δεν έπρεπε να βγει τίποτα γιατί εγώ είμαι σκεπτικιστής και ο Πάβελ είναι ονειροπόλος. Κάθε φορά που πρότεινε μια ιδέα, πάντα δεν πίστευα σε αυτήν και αρνιόμουν να συμμετάσχω. Αλλά θέλαμε πολύ να ανοίξουμε τη δική μας επιχείρηση.
Τελικά, μπορέσαμε να βρούμε μια επιλογή που να ταιριάζει και στους δύο μας και να κάνουμε αυτό που ξέρουμε να κάνουμε. Το 2016, αποφασίσαμε να δημιουργήσουμε μια εταιρεία πληροφορικής που θα βοηθούσε τις επιχειρήσεις να λύσουν προβλήματα πληροφορικής. Πρόκειται για την ανάπτυξη συστημάτων πληροφορικής (1C, τερματικό διακομιστή, διακομιστή αλληλογραφίας κ.λπ.), τη συντήρησή τους, το κλασικό HelpDesk για χρήστες και τη διαχείριση δικτύου.
Ειλικρινά μιλώντας, τη στιγμή της δημιουργίας της εταιρείας, δεν πίστευα σε αυτό περίπου το 99,9%. Αλλά με κάποιο τρόπο ο Πάβελ μπόρεσε να με κάνει να προσπαθήσω και κοιτάζοντας μπροστά, αποδείχτηκε ότι είχε δίκιο. Ο Πάβελ και εγώ ρίξαμε 300 ρούβλια ο καθένας, καταχωρήσαμε μια νέα LLC "Audit-Telecom", νοικιάσαμε ένα μικροσκοπικό γραφείο, φτιάξαμε ωραίες επαγγελματικές κάρτες, γενικά, όπως πιθανώς οι περισσότεροι άπειροι, αρχάριοι επιχειρηματίες και αρχίσαμε να ψάχνουμε πελάτες. Η εύρεση πελατών είναι μια εντελώς διαφορετική ιστορία. Ίσως θα γράψουμε ένα ξεχωριστό άρθρο ως μέρος του εταιρικού ιστολογίου εάν κάποιος ενδιαφέρεται. Ψυχρά κλήσεις, φυλλάδια κ.λπ. Αυτό δεν έδωσε κανένα αποτέλεσμα. Όπως διάβασα τώρα από πολλές ιστορίες για τις επιχειρήσεις, με τον ένα ή τον άλλο τρόπο, πολλά εξαρτώνται από την τύχη. Είμασταν τυχεροί. και κυριολεκτικά μερικές εβδομάδες μετά τη δημιουργία της εταιρείας, μας πλησίασε ο αδερφός μου Βλαντιμίρ, ο οποίος μας έφερε τον πρώτο μας πελάτη. Δεν θα σας κουράσω με τις λεπτομέρειες της συνεργασίας με πελάτες, δεν πρόκειται για αυτό το άρθρο, απλώς θα πω ότι πήγαμε για έλεγχο, εντοπίσαμε κρίσιμες περιοχές και αυτοί οι τομείς χάλασαν ενώ πάρθηκε η απόφαση για το αν θα συνεργάζονται μαζί μας σε συνεχή βάση ως εξωτερικοί ανάδοχοι. Μετά από αυτό, ελήφθη αμέσως μια θετική απόφαση.
Στη συνέχεια, κυρίως από στόμα σε στόμα μέσω φίλων, άρχισαν να εμφανίζονται και άλλες εταιρείες παροχής υπηρεσιών. Το Helpdesk ήταν σε ένα σύστημα. Οι συνδέσεις με τον εξοπλισμό δικτύου και τους διακομιστές είναι διαφορετικές ή μάλλον διαφορετικές. Μερικοί άνθρωποι αποθήκευσαν συντομεύσεις, άλλοι χρησιμοποίησαν βιβλία διευθύνσεων RDP. Η παρακολούθηση είναι ένα άλλο ξεχωριστό σύστημα. Είναι πολύ άβολο για μια ομάδα να εργάζεται σε διαφορετικά συστήματα. Σημαντικές πληροφορίες χάνονται από τα μάτια μας. Λοιπόν, για παράδειγμα, ο τερματικός διακομιστής του πελάτη έγινε μη διαθέσιμος. Οι αιτήσεις από τους χρήστες αυτού του πελάτη λαμβάνονται αμέσως. Ο ειδικός υποστήριξης ανοίγει ένα αίτημα (λήφθηκε τηλεφωνικά). Εάν περιστατικά και αιτήματα καταχωρούνταν σε ένα σύστημα, τότε ο ειδικός υποστήριξης θα έβλεπε αμέσως ποιο είναι το πρόβλημα του χρήστη και θα του το έλεγε, ενώ ταυτόχρονα θα συνδεόταν με το απαιτούμενο αντικείμενο για να επιλύσει την κατάσταση. Όλοι γνωρίζουν την τακτική κατάσταση και λειτουργούν αρμονικά. Δεν έχουμε βρει ένα σύστημα που να συνδυάζονται όλα αυτά. Έγινε σαφές ότι ήρθε η ώρα να φτιάξουμε το δικό μας προϊόν.
Συνεχίστε την εργασία στο σύστημα παρακολούθησης
Ήταν σαφές ότι το σύστημα που γράφτηκε νωρίτερα ήταν εντελώς ακατάλληλο για τις τρέχουσες εργασίες. Ούτε από πλευράς λειτουργικότητας ούτε από πλευράς ποιότητας. Και αποφασίστηκε να γραφτεί το σύστημα από την αρχή. Γραφικά θα έπρεπε να φαίνεται εντελώς διαφορετικό. Έπρεπε να είναι ένα ιεραρχικό σύστημα έτσι ώστε να είναι δυνατό να ανοίξει γρήγορα και άνετα το σωστό αντικείμενο για τον σωστό πελάτη. Το σχήμα όπως στην πρώτη εκδοχή δεν ήταν απολύτως δικαιολογημένο στην παρούσα περίπτωση, γιατί Οι πελάτες είναι διαφορετικοί και δεν είχε καμία σημασία σε ποιες εγκαταστάσεις βρισκόταν ο εξοπλισμός. Αυτό έχει ήδη μεταφερθεί στην τεκμηρίωση.
Τα καθήκοντα λοιπόν είναι:
- Ιεραρχική δομή;
- Κάποιο τμήμα διακομιστή που μπορεί να τοποθετηθεί στις εγκαταστάσεις του πελάτη με τη μορφή εικονικής μηχανής για να συλλέξει τις μετρήσεις που χρειαζόμαστε και να το στείλει στον κεντρικό διακομιστή, ο οποίος θα συνοψίσει όλα αυτά και θα μας τα δείξει.
- Ειδοποιήσεις. Αυτά που δεν πρέπει να χάσετε, γιατί... εκεινη την ωρα δεν ηταν δυνατον καποιος να καθεται και να κοιταει απλα την οθονη?
- Σύστημα εφαρμογής. Άρχισαν να εμφανίζονται πελάτες για τους οποίους εξυπηρετήσαμε όχι μόνο εξοπλισμό διακομιστή και δικτύου, αλλά και σταθμούς εργασίας.
- Δυνατότητα γρήγορης σύνδεσης με διακομιστές και εξοπλισμό από το σύστημα.
Οι εργασίες έχουν τεθεί, αρχίζουμε να γράφουμε. Στην πορεία, επεξεργασία αιτημάτων από πελάτες. Εκείνη την εποχή ήμασταν ήδη 4 άτομα. Ξεκινήσαμε να γράφουμε και τα δύο μέρη ταυτόχρονα: τον κεντρικό διακομιστή και τον διακομιστή για εγκατάσταση σε πελάτες. Σε αυτό το σημείο, το Linux δεν ήταν πλέον άγνωστο για εμάς και αποφασίστηκε ότι οι εικονικές μηχανές που θα είχαν οι πελάτες θα ήταν στο Debian. Δεν θα υπάρχουν προγράμματα εγκατάστασης, απλώς θα κάνουμε ένα έργο τμήματος διακομιστή σε μια συγκεκριμένη εικονική μηχανή και, στη συνέχεια, θα το κλωνοποιήσουμε στον επιθυμητό πελάτη. Αυτό ήταν άλλο ένα λάθος. Αργότερα έγινε σαφές ότι σε ένα τέτοιο σχήμα ο μηχανισμός ενημέρωσης δεν είχε αναπτυχθεί εντελώς. Εκείνοι. προσθέταμε κάποια νέα δυνατότητα και, στη συνέχεια, υπήρχε όλο το πρόβλημα της διανομής της σε όλους τους διακομιστές πελατών, αλλά θα επανέλθουμε σε αυτό αργότερα, όλα εντάξει.
Φτιάξαμε το πρώτο πρωτότυπο. Μπόρεσε να κάνει ping στις συσκευές και τους διακομιστές δικτύου πελατών που χρειαζόμασταν και να στείλει αυτά τα δεδομένα στον κεντρικό μας διακομιστή. Και αυτός, με τη σειρά του, ενημέρωσε αυτά τα δεδομένα μαζικά στον κεντρικό διακομιστή. Εδώ θα γράψω όχι μόνο μια ιστορία για το πώς και τι πέτυχε, αλλά και ποια ερασιτεχνικά λάθη έγιναν και πώς αργότερα έπρεπε να το πληρώσω με τον καιρό. Έτσι, ολόκληρο το δέντρο των αντικειμένων αποθηκεύτηκε σε ένα μόνο αρχείο με τη μορφή ενός σειριακού αντικειμένου. Ενώ συνδέσαμε αρκετούς πελάτες στο σύστημα, όλα ήταν λίγο πολύ φυσιολογικά, αν και μερικές φορές υπήρχαν κάποια αντικείμενα που ήταν εντελώς ακατανόητα. Αλλά όταν συνδέσαμε μια ντουζίνα διακομιστές στο σύστημα, άρχισαν να γίνονται θαύματα. Μερικές φορές, για κάποιο άγνωστο λόγο, όλα τα αντικείμενα στο σύστημα απλώς εξαφανίζονταν. Είναι σημαντικό εδώ να σημειωθεί ότι οι διακομιστές που οι πελάτες είχαν στείλει δεδομένα στον κεντρικό διακομιστή κάθε λίγα δευτερόλεπτα μέσω αιτήματος POST. Ένας προσεκτικός αναγνώστης και ένας έμπειρος προγραμματιστής ήδη μάντευαν ότι υπήρχε πρόβλημα πολλαπλής πρόσβασης στο ίδιο το αρχείο στο οποίο το σειριακό αντικείμενο ήταν αποθηκευμένο από διαφορετικά νήματα ταυτόχρονα. Και ακριβώς όταν συνέβαινε αυτό, έγιναν θαύματα με την εξαφάνιση αντικειμένων. Το αρχείο απλά έγινε κενό. Αλλά όλα αυτά δεν ανακαλύφθηκαν αμέσως, αλλά μόνο κατά τη λειτουργία με αρκετούς διακομιστές. Κατά τη διάρκεια αυτής της περιόδου, προστέθηκε η λειτουργία σάρωσης θυρών (οι διακομιστές έστειλαν στο κεντρικό όχι μόνο πληροφορίες σχετικά με τη διαθεσιμότητα των συσκευών, αλλά και σχετικά με τις θύρες που είναι ανοιχτές σε αυτές). Αυτό έγινε καλώντας την εντολή:
$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);
τα αποτελέσματα ήταν συχνά λανθασμένα και οι σαρώσεις χρειάστηκαν πολύ χρόνο για να ολοκληρωθούν. Ξέχασα τελείως το ping, έγινε μέσω fping:
system("fping -r 3 -t 100 {$this->ip}");
Και αυτό δεν παραλληλίστηκε και επομένως η διαδικασία ήταν πολύ μεγάλη. Αργότερα, ολόκληρη η λίστα των διευθύνσεων IP που απαιτούνται για την επαλήθευση στάλθηκε αμέσως στο fping και λάβαμε μια έτοιμη λίστα με όσους απάντησαν. Σε αντίθεση με εμάς, το fping ήταν σε θέση να παραλληλίσει τις διαδικασίες.
Μια άλλη συνηθισμένη εργασία ρουτίνας ήταν η ρύθμιση ορισμένων υπηρεσιών μέσω WEB. Λοιπόν, για παράδειγμα, ECP από το MS Exchange. Βασικά είναι απλώς ένας σύνδεσμος. Και αποφασίσαμε ότι πρέπει να μπορούμε να προσθέτουμε τέτοιους συνδέσμους απευθείας στο σύστημα, ώστε να μην χρειάζεται να ψάχνουμε στην τεκμηρίωση ή κάπου αλλού σε σελιδοδείκτες για τον τρόπο πρόσβασης στο ECP ενός συγκεκριμένου πελάτη. Έτσι εμφανίστηκε η έννοια των συνδέσμων πόρων για το σύστημα, η λειτουργικότητά τους είναι διαθέσιμη μέχρι σήμερα και δεν έχει αλλάξει, καλά, σχεδόν.
Πώς λειτουργούν οι σύνδεσμοι πόρων στο Veliam
Απομακρυσμένες συνδέσεις
Έτσι φαίνεται σε δράση στην τρέχουσα έκδοση του Veliam
Μία από τις εργασίες ήταν η γρήγορη και εύκολη σύνδεση με διακομιστές, από τους οποίους υπήρχαν ήδη πολλοί (περισσότεροι από εκατό) και η ταξινόμηση μέσω εκατομμυρίων προαποθηκευμένων συντομεύσεων RDP ήταν εξαιρετικά άβολη. Χρειαζόταν ένα εργαλείο. Υπάρχει λογισμικό στο Διαδίκτυο που είναι κάτι σαν βιβλίο διευθύνσεων για τέτοιες συνδέσεις RDP, αλλά δεν είναι ενσωματωμένο στο σύστημα παρακολούθησης και δεν μπορούν να αποθηκευτούν λογαριασμοί. Η είσοδος λογαριασμών για διαφορετικούς πελάτες κάθε φορά είναι σκέτη κόλαση όταν συνδέεστε δεκάδες φορές την ημέρα σε διαφορετικούς διακομιστές. Με το SSH, τα πράγματα είναι λίγο καλύτερα· υπάρχει πολύ καλό λογισμικό που σας επιτρέπει να οργανώνετε τέτοιες συνδέσεις σε φακέλους και να θυμάστε τους λογαριασμούς από αυτούς. Υπάρχουν όμως 2 προβλήματα. Το πρώτο είναι ότι δεν βρήκαμε ούτε ένα πρόγραμμα για συνδέσεις RDP και SSH. Το δεύτερο είναι ότι εάν κάποια στιγμή δεν είμαι στον υπολογιστή μου και πρέπει να συνδεθώ γρήγορα ή απλώς επανεγκαταστήσω το σύστημα, θα πρέπει να μπω στην τεκμηρίωση για να κοιτάξω τον λογαριασμό από αυτόν τον πελάτη. Είναι άβολο και χάσιμο χρόνου.
Η ιεραρχική δομή που χρειαζόμασταν για τους διακομιστές πελατών ήταν ήδη διαθέσιμη στο εσωτερικό μας προϊόν. Απλώς έπρεπε να καταλάβω πώς να συνδέσω γρήγορες συνδέσεις στον απαραίτητο εξοπλισμό εκεί. Για αρχή, τουλάχιστον εντός του δικτύου σας.
Λαμβάνοντας υπόψη το γεγονός ότι ο πελάτης στο σύστημά μας ήταν ένα πρόγραμμα περιήγησης που δεν είχε πρόσβαση στους τοπικούς πόρους του υπολογιστή, για να εκκινήσουμε απλά την εφαρμογή που χρειαζόμασταν με κάποια εντολή, εφευρέθηκε να κάνουμε τα πάντα μέσω των "Windows προσαρμοσμένο σχήμα url». Έτσι εμφανίστηκε ένα συγκεκριμένο «πρόσθετο» για το σύστημά μας, το οποίο απλώς περιελάμβανε το Putty και το Remote Desktop Plus και, κατά την εγκατάσταση, απλώς κατέγραψε το σχήμα URI στα Windows. Τώρα, όταν θέλαμε να συνδεθούμε σε ένα αντικείμενο μέσω RDP ή SSH, κάναμε κλικ σε αυτήν την ενέργεια στο σύστημά μας και το Προσαρμοσμένο URI λειτούργησε. Κυκλοφόρησε το τυπικό mstsc.exe ενσωματωμένο στα Windows ή το putty, το οποίο αποτελούσε μέρος του "πρόσθετου". Έβαλα τη λέξη plugin σε εισαγωγικά γιατί δεν πρόκειται για πρόσθετο προγράμματος περιήγησης με την κλασική έννοια.
Τουλάχιστον αυτό ήταν κάτι. Βολικό βιβλίο διευθύνσεων. Επιπλέον, στην περίπτωση του Putty, όλα ήταν γενικά καλά· θα μπορούσαν να δοθούν συνδέσεις IP, σύνδεση και κωδικός πρόσβασης ως παράμετροι εισόδου. Εκείνοι. Έχουμε ήδη συνδεθεί σε διακομιστές Linux στο δίκτυό μας με ένα κλικ χωρίς να εισάγουμε κωδικούς πρόσβασης. Αλλά με το RDP δεν είναι τόσο απλό. Το τυπικό mstsc δεν μπορεί να παρέχει διαπιστευτήρια ως παραμέτρους. Το Remote Desktop Plus ήρθε στη διάσωση. Το επέτρεψε να συμβεί αυτό. Τώρα μπορούμε να το κάνουμε χωρίς αυτό, αλλά για πολύ καιρό ήταν ένας πιστός βοηθός στο σύστημά μας. Με τους ιστότοπους HTTP(S) όλα είναι απλά, τέτοια αντικείμενα απλά ανοίγουν στο πρόγραμμα περιήγησης και αυτό είναι. Βολικό και πρακτικό. Αλλά αυτή ήταν ευτυχία μόνο στο εσωτερικό δίκτυο.
Δεδομένου ότι επιλύσαμε τη συντριπτική πλειονότητα των προβλημάτων εξ αποστάσεως από το γραφείο, το πιο εύκολο πράγμα ήταν να διαθέσουμε VPN στους πελάτες. Και τότε ήταν δυνατή η σύνδεση μαζί τους από το σύστημά μας. Αλλά ήταν ακόμα κάπως άβολο. Για κάθε πελάτη, ήταν απαραίτητο να διατηρηθεί μια δέσμη απομνημονευμένων συνδέσεων VPN σε κάθε υπολογιστή και πριν από τη σύνδεση σε οποιαδήποτε, ήταν απαραίτητο να ενεργοποιηθεί το αντίστοιχο VPN. Χρησιμοποιήσαμε αυτή τη λύση για αρκετό καιρό. Αλλά ο αριθμός των πελατών αυξάνεται, ο αριθμός των VPN αυξάνεται επίσης, και όλα αυτά άρχισαν να πιέζονται και κάτι έπρεπε να γίνει γι 'αυτό. Τα δάκρυα ήρθαν ιδιαίτερα μετά την επανεγκατάσταση του συστήματος, όταν έπρεπε να εισαγάγω ξανά δεκάδες συνδέσεις VPN σε ένα νέο προφίλ των Windows. Σταμάτα να το ανέχεσαι, είπα, και άρχισα να σκέφτομαι τι θα μπορούσα να κάνω για αυτό.
Έτυχε όλοι οι πελάτες να έχουν ως δρομολογητές συσκευές της γνωστής εταιρείας Mikrotik. Είναι πολύ λειτουργικά και βολικά για την εκτέλεση σχεδόν οποιασδήποτε εργασίας. Το μειονέκτημα είναι ότι είναι "πειρατές". Επιλύσαμε αυτό το πρόβλημα απλά κλείνοντας κάθε πρόσβαση από το εξωτερικό. Αλλά ήταν απαραίτητο με κάποιο τρόπο να έχουμε πρόσβαση σε αυτά χωρίς να έρθετε στο χώρο του πελάτη, γιατί... ειναι μακρυ. Απλώς φτιάξαμε τούνελ για κάθε τέτοιο Mikrotik και τα χωρίσαμε σε ξεχωριστή πισίνα. χωρίς καμία δρομολόγηση, ώστε να μην υπάρχει σύνδεση του δικτύου σας με τα δίκτυα των πελατών και τα δίκτυά τους μεταξύ τους.
Η ιδέα γεννήθηκε για να βεβαιωθώ ότι όταν κάνω κλικ στο αντικείμενο που χρειάζομαι στο σύστημα, ο κεντρικός διακομιστής παρακολούθησης, γνωρίζοντας τους λογαριασμούς SSH όλων των πελατών Mikrotik, συνδέεται με τον επιθυμητό, δημιουργεί έναν κανόνα προώθησης στον επιθυμητό κεντρικό υπολογιστή με το απαιτούμενη θύρα. Υπάρχουν πολλά σημεία εδώ. Η λύση δεν είναι καθολική - θα λειτουργήσει μόνο για τη Mikrotik, καθώς η σύνταξη εντολών είναι διαφορετική για όλους τους δρομολογητές. Επίσης, τέτοιες προωθήσεις έπρεπε να διαγραφούν με κάποιο τρόπο και το τμήμα διακομιστή του συστήματός μας ουσιαστικά δεν μπορούσε να παρακολουθήσει με κανέναν τρόπο εάν είχα ολοκληρώσει την περίοδο λειτουργίας RDP. Λοιπόν, μια τέτοια προώθηση είναι μια τρύπα για τον πελάτη. Αλλά δεν επιδιώξαμε την καθολικότητα, γιατί... το προϊόν χρησιμοποιήθηκε μόνο εντός της εταιρείας μας και δεν υπήρχε καμία σκέψη να κυκλοφορήσει στο κοινό.
Κάθε ένα από τα προβλήματα λύθηκε με τον δικό του τρόπο. Όταν δημιουργήθηκε ο κανόνας, αυτή η προώθηση ήταν διαθέσιμη μόνο για μία συγκεκριμένη εξωτερική διεύθυνση IP (από την οποία αρχικοποιήθηκε η σύνδεση). Έτσι αποφεύχθηκε μια τρύπα ασφαλείας. Αλλά με κάθε τέτοια σύνδεση, ένας κανόνας Mikrotik προστέθηκε στη σελίδα NAT και δεν διαγραφόταν. Και όλοι γνωρίζουν ότι όσο περισσότεροι κανόνες υπάρχουν, τόσο περισσότερο φορτώνεται ο επεξεργαστής του δρομολογητή. Και γενικά, δεν μπορούσα να δεχτώ ότι μια μέρα θα πήγαινα σε κάποιο Mikrotik, και θα υπήρχαν εκατοντάδες νεκροί, άχρηστοι κανόνες.
Εφόσον ο διακομιστής μας δεν μπορεί να παρακολουθήσει την κατάσταση της σύνδεσης, αφήστε τη Mikrotik να τις παρακολουθεί η ίδια. Και έγραψα ένα σενάριο που παρακολουθούσε συνεχώς όλους τους κανόνες προώθησης με μια συγκεκριμένη περιγραφή και έλεγξα αν η σύνδεση TCP είχε έναν κατάλληλο κανόνα. Εάν δεν υπάρχει για κάποιο χρονικό διάστημα, τότε η σύνδεση πιθανότατα έχει ήδη ολοκληρωθεί και αυτή η προώθηση μπορεί να διαγραφεί. Όλα πήγαν καλά, το σενάριο λειτούργησε καλά.
Παρεμπιπτόντως, εδώ είναι:
global atmonrulecounter {"dontDelete"="dontDelete"}
:foreach i in=[/ip firewall nat find comment~"atmon_script_main"] do={
local dstport [/ip firewall nat get value-name="dst-port" $i]
local dstaddress [/ip firewall nat get value-name="dst-address" $i]
local dstaddrport "$dstaddress:$dstport"
#log warning message=$dstaddrport
local thereIsCon [/ip firewall connection find dst-address~"$dstaddrport"]
if ($thereIsCon = "") do={
set ($atmonrulecounter->$dstport) ($atmonrulecounter->$dstport + 1)
#:log warning message=($atmonrulecounter->$dstport)
if (($atmonrulecounter->$dstport) > 5) do={
#log warning message="Removing nat rules added automaticaly by atmon_script"
/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_main_$dstport"]
/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_sub_$dstport"]
set ($atmonrulecounter->$dstport) 0
}
} else {
set ($atmonrulecounter->$dstport) 0
}
}
Σίγουρα θα μπορούσε να είχε γίνει πιο όμορφο, πιο γρήγορο κ.λπ., αλλά δούλεψε, δεν φόρτωσε τη Mikrotik και έκανε εξαιρετική δουλειά. Τελικά μπορέσαμε να συνδεθούμε με τους διακομιστές των πελατών και τον εξοπλισμό δικτύου με ένα μόνο κλικ. Χωρίς άνοιγμα VPN ή εισαγωγή κωδικών πρόσβασης. Το σύστημα έχει γίνει πολύ βολικό για εργασία. Ο χρόνος εξυπηρέτησης μειώθηκε και όλοι ξοδέψαμε χρόνο δουλεύοντας αντί να συνδεθούμε με τα απαραίτητα αντικείμενα.
Mikrotik Backup
Διαμορφώσαμε το αντίγραφο ασφαλείας όλων των Mikrotik σε FTP. Και γενικά όλα ήταν καλά. Αλλά όταν χρειαζόταν να λάβετε ένα αντίγραφο ασφαλείας, έπρεπε να ανοίξετε αυτό το FTP και να το αναζητήσετε εκεί. Έχουμε ένα σύστημα στο οποίο είναι συνδεδεμένοι όλοι οι δρομολογητές· μπορούμε να επικοινωνήσουμε με συσκευές μέσω SSH. Γιατί δεν το κάνουμε έτσι ώστε το ίδιο το σύστημα να παίρνει αντίγραφα ασφαλείας από όλα τα Mikrotik καθημερινά, σκέφτηκα. Και άρχισε να το εφαρμόζει. Συνδεθήκαμε, δημιουργήσαμε ένα αντίγραφο ασφαλείας και το μεταφέραμε στον αποθηκευτικό χώρο.
Κώδικας δέσμης ενεργειών σε PHP για λήψη αντιγράφου ασφαλείας από τη Mikrotik:
<?php
$IP = '0.0.0.0';
$LOGIN = 'admin';
$PASSWORD = '';
$BACKUP_NAME = 'test';
$connection = ssh2_connect($IP, 22);
if (!ssh2_auth_password($connection, $LOGIN, $PASSWORD)) exit;
ssh2_exec($connection, '/system backup save name="atmon" password="atmon"');
stream_get_contents($connection);
ssh2_exec($connection, '/export file="atmon.rsc"');
stream_get_contents($connection);
sleep(40); // Waiting bakup makes
$sftp = ssh2_sftp($connection);
// Download backup file
$size = filesize("ssh2.sftp://$sftp/atmon.backup");
$stream = fopen("ssh2.sftp://$sftp/atmon.backup", 'r');
$contents = '';
$read = 0;
$len = $size;
while ($read < $len && ($buf = fread($stream, $len - $read))) {
$read += strlen($buf);
$contents .= $buf;
}
file_put_contents ($BACKUP_NAME . ‘.backup’,$contents);
@fclose($stream);
sleep(3);
// Download RSC file
$size = filesize("ssh2.sftp://$sftp/atmon.rsc");
$stream = fopen("ssh2.sftp://$sftp/atmon.rsc", 'r');
$contents = '';
$read = 0;
$len = $size;
while ($read < $len && ($buf = fread($stream, $len - $read))) {
$read += strlen($buf);
$contents .= $buf;
}
file_put_contents ($BACKUP_NAME . ‘.rsc’,$contents);
@fclose($stream);
ssh2_exec($connection, '/file remove atmon.backup');
ssh2_exec($connection, '/file remove atmon.rsc');
?>
Το αντίγραφο ασφαλείας λαμβάνεται σε δύο μορφές - δυαδική και διαμόρφωση κειμένου. Το δυαδικό βοηθά στη γρήγορη επαναφορά των απαιτούμενων παραμέτρων και το κείμενο σάς επιτρέπει να κατανοήσετε τι πρέπει να κάνετε εάν υπάρχει αναγκαστική αντικατάσταση του εξοπλισμού και το δυαδικό δεν μπορεί να μεταφορτωθεί σε αυτό. Ως αποτέλεσμα, έχουμε μια άλλη βολική λειτουργικότητα στο σύστημα. Επιπλέον, κατά την προσθήκη νέου Mikrotik, δεν χρειαζόταν να ρυθμίσετε τίποτα· απλώς πρόσθεσα το αντικείμενο στο σύστημα και δημιούργησα έναν λογαριασμό για αυτό μέσω SSH. Στη συνέχεια, το ίδιο το σύστημα φρόντισε για τη λήψη αντιγράφων ασφαλείας. Η τρέχουσα έκδοση του SaaS Veliam δεν διαθέτει ακόμη αυτήν τη λειτουργία, αλλά θα τη μεταφέρουμε σύντομα.
Στιγμιότυπα οθόνης του πώς έμοιαζε στο εσωτερικό σύστημα
Μετάβαση στην κανονική αποθήκευση βάσης δεδομένων
Έγραψα ήδη παραπάνω ότι εμφανίστηκαν αντικείμενα. Μερικές φορές ολόκληρη η λίστα των αντικειμένων στο σύστημα απλώς εξαφανιζόταν, μερικές φορές κατά την επεξεργασία ενός αντικειμένου, οι πληροφορίες δεν αποθηκεύονταν και το αντικείμενο έπρεπε να μετονομαστεί τρεις φορές. Αυτό εκνεύρισε τους πάντες τρομερά. Η εξαφάνιση αντικειμένων συνέβαινε σπάνια και αποκαταστάθηκε εύκολα με την επαναφορά αυτού του αρχείου, αλλά αποτυχίες κατά την επεξεργασία αντικειμένων συνέβαιναν αρκετά συχνά. Πιθανώς, αρχικά δεν το έκανα μέσω της βάσης δεδομένων, επειδή δεν χωρούσε στο μυαλό μου πώς ήταν δυνατόν να κρατήσω ένα δέντρο με όλες τις συνδέσεις σε ένα επίπεδο τραπέζι. Είναι επίπεδο, αλλά το δέντρο είναι ιεραρχικό. Αλλά μια καλή λύση για πολλαπλή πρόσβαση, και στη συνέχεια (καθώς το σύστημα γίνεται πιο περίπλοκο) συναλλακτικό, είναι ένα DBMS. Μάλλον δεν είμαι ο πρώτος που αντιμετωπίζει αυτό το πρόβλημα. Άρχισα να γκουγκλάρω. Αποδείχθηκε ότι τα πάντα είχαν εφευρεθεί πριν από μένα και υπάρχουν αρκετοί αλγόριθμοι που χτίζουν ένα δέντρο από ένα επίπεδο τραπέζι. Αφού κοίταξα το καθένα, υλοποίησα ένα από αυτά. Αλλά αυτή ήταν ήδη μια νέα έκδοση του συστήματος, επειδή... Στην πραγματικότητα, λόγω αυτού, έπρεπε να ξαναγράψω αρκετά. Το αποτέλεσμα ήταν φυσικό, τα προβλήματα τυχαίας συμπεριφοράς του συστήματος εξαφανίστηκαν. Κάποιοι θα μπορούσαν να πουν ότι τα σφάλματα είναι πολύ ερασιτεχνικά (σενάρια με ένα νήμα, αποθήκευση πληροφοριών στις οποίες έγινε πρόσβαση πολλές φορές ταυτόχρονα από διαφορετικά νήματα σε ένα αρχείο, κ.λπ.) στον τομέα της ανάπτυξης λογισμικού. Ίσως αυτό να είναι αλήθεια, αλλά η κύρια δουλειά μου ήταν η διοίκηση, και ο προγραμματισμός ήταν μια παράπλευρη φασαρία για την ψυχή μου, και απλά δεν είχα εμπειρία να δουλεύω σε μια ομάδα προγραμματιστών, όπου τέτοια βασικά πράγματα θα μου είχαν προτείνει αμέσως ο ανώτερός μου σύντροφοι. Επομένως, γέμισα μόνος μου όλα αυτά τα χτυπήματα, αλλά έμαθα πολύ καλά το υλικό. Και επίσης, η δουλειά μου περιλαμβάνει συναντήσεις με πελάτες, ενέργειες που στοχεύουν στην προσπάθεια προώθησης της εταιρείας, ένα σωρό διοικητικά ζητήματα εντός της εταιρείας και πολλά, πολλά άλλα. Αλλά με τον ένα ή τον άλλο τρόπο, αυτό που υπήρχε ήδη ήταν σε ζήτηση. Τα παιδιά και εγώ ο ίδιος χρησιμοποιούσαμε το προϊόν στην καθημερινή μας δουλειά. Υπήρχαν ειλικρινά αποτυχημένες ιδέες και λύσεις για τις οποίες χάθηκε χρόνος, αλλά στο τέλος έγινε σαφές ότι αυτό δεν ήταν εργαλείο εργασίας και κανείς δεν το χρησιμοποίησε και δεν κατέληξε στον Βέλιαμ.
Helpdesk - HelpDesk
Δεν θα ήταν λάθος να αναφέρουμε πώς δημιουργήθηκε το HelpDesk. Αυτή είναι μια εντελώς διαφορετική ιστορία, γιατί... στο Veliam αυτή είναι ήδη η 3η εντελώς νέα έκδοση, η οποία είναι διαφορετική από όλες τις προηγούμενες. Τώρα είναι ένα απλό σύστημα, διαισθητικό χωρίς περιττά κουδούνια και σφυρίχτρες, με δυνατότητα ενοποίησης με έναν τομέα, καθώς και δυνατότητα πρόσβασης στο ίδιο προφίλ χρήστη από οπουδήποτε χρησιμοποιώντας έναν σύνδεσμο από ένα email. Και το πιο σημαντικό, είναι δυνατή η σύνδεση με τον αιτούντα μέσω VNC από οπουδήποτε (στο σπίτι ή στο γραφείο) απευθείας από την εφαρμογή χωρίς VPN ή προώθηση θύρας. Θα σας πω πώς φτάσαμε σε αυτό, τι συνέβη πριν και τι τρομερές αποφάσεις ελήφθησαν.
Συνδεθήκαμε με τους χρήστες μέσω του γνωστού TeamViewer. Όλοι οι υπολογιστές των οποίων οι χρήστες εξυπηρετούμε έχουν εγκατεστημένη τηλεόραση. Το πρώτο πράγμα που κάναμε λάθος και στη συνέχεια το αφαιρέσαμε, ήταν να συνδέσουμε κάθε πελάτη HD με το υλικό. Πώς συνδέθηκε ο χρήστης στο σύστημα HD για να υποβάλει αίτημα; Εκτός από την τηλεόραση, όλοι είχαν ένα ειδικό βοηθητικό πρόγραμμα εγκατεστημένο στους υπολογιστές τους, γραμμένο στα Lazarus (πολλοί εδώ θα κάνουν τα μάτια τους με τα στραβά μάτια, και ίσως ακόμη και να πάνε στο Google τι είναι, αλλά η καλύτερη μεταγλωττισμένη γλώσσα που ήξερα ήταν η Delphi, και η Lazarus είναι σχεδόν το ίδιο πράγμα, μόνο δωρεάν). Γενικά, ο χρήστης εκτόξευσε ένα ειδικό αρχείο δέσμης που εκκίνησε αυτό το βοηθητικό πρόγραμμα, το οποίο με τη σειρά του διάβαζε το HWID του συστήματος και μετά εκκινήθηκε το πρόγραμμα περιήγησης και έλαβε χώρα εξουσιοδότηση. Γιατί έγινε αυτό; Σε ορισμένες εταιρείες, ο αριθμός των εξυπηρετούμενων χρηστών υπολογίζεται μεμονωμένα και η τιμή της υπηρεσίας για κάθε μήνα βασίζεται στον αριθμό των ατόμων. Αυτό είναι κατανοητό, λέτε, αλλά γιατί είναι συνδεδεμένο με το υλικό; Είναι πολύ απλό, κάποια άτομα ήρθαν στο σπίτι και έκαναν ένα αίτημα από τον φορητό υπολογιστή του σπιτιού τους με το στυλ του «κάνε τα πάντα όμορφα για μένα εδώ». Εκτός από την ανάγνωση του συστήματος HWID, το βοηθητικό πρόγραμμα τράβηξε το τρέχον αναγνωριστικό Teamviewer από το μητρώο και το μετέδωσε επίσης σε εμάς. Το Teamviewer έχει ένα API για ενσωμάτωση. Και κάναμε αυτή την ενσωμάτωση. Αλλά υπήρχε ένα πιάσιμο. Μέσω αυτών των API, είναι αδύνατη η σύνδεση στον υπολογιστή του χρήστη όταν δεν εκκινεί ρητά αυτή τη συνεδρία και αφού προσπαθήσει να συνδεθεί σε αυτόν, πρέπει επίσης να κάνει κλικ στο «επιβεβαίωση». Εκείνη τη στιγμή, μας φαινόταν λογικό ότι κανείς δεν θα έπρεπε να συνδεθεί χωρίς το αίτημα του χρήστη και δεδομένου ότι το άτομο βρίσκεται στον υπολογιστή, θα ξεκινήσει τη συνεδρία και θα απαντήσει θετικά στο αίτημα απομακρυσμένης σύνδεσης. Όλα έγιναν λάθος. Οι υποψήφιοι ξέχασαν να πατήσουν την έναρξη της συνεδρίας και έπρεπε να τους το πουν αυτό σε μια τηλεφωνική συνομιλία. Αυτό έχασε χρόνο και ήταν απογοητευτικό και στις δύο πλευρές της διαδικασίας. Επιπλέον, δεν είναι καθόλου ασυνήθιστο για τέτοιες στιγμές όταν ένα άτομο αφήνει ένα αίτημα, αλλά επιτρέπεται να συνδεθεί μόνο όταν φεύγει για μεσημεριανό γεύμα. Γιατί το πρόβλημα δεν είναι κρίσιμο και δεν θέλει να διακοπεί η εργασιακή του διαδικασία. Συνεπώς, δεν θα πατήσει κανένα κουμπί για να επιτρέψει τη σύνδεση. Έτσι εμφανίστηκε πρόσθετη λειτουργικότητα κατά τη σύνδεση στο HelpDesk - διαβάζοντας το αναγνωριστικό του Teamviwer. Γνωρίζαμε τον μόνιμο κωδικό πρόσβασης που χρησιμοποιήθηκε κατά την εγκατάσταση του Teamviwer. Πιο συγκεκριμένα, μόνο το σύστημα το γνώριζε, αφού ήταν ενσωματωμένο στον εγκαταστάτη και στο σύστημά μας. Αντίστοιχα, υπήρχε ένα κουμπί σύνδεσης από την εφαρμογή κάνοντας κλικ στο οποίο δεν χρειαζόταν να περιμένετε τίποτα, αλλά το Teamviewer άνοιξε αμέσως και έγινε σύνδεση. Ως αποτέλεσμα, υπήρχαν δύο τύποι πιθανών συνδέσεων. Μέσω του επίσημου API του Teamviewer και του ίδιου μας. Προς έκπληξή μου, σταμάτησαν να χρησιμοποιούν το πρώτο σχεδόν αμέσως, αν και υπήρχε οδηγία για χρήση μόνο σε ειδικές περιπτώσεις και όταν ο ίδιος ο χρήστης δώσει το πράσινο φως. Παρόλα αυτά, δώσε μου ασφάλεια τώρα. Αλλά αποδείχθηκε ότι οι αιτούντες δεν το χρειάζονταν αυτό. Είναι όλα απολύτως καλά με τη σύνδεση τους χωρίς κουμπί επιβεβαίωσης.
Μετάβαση σε multithreading στο Linux
Το ζήτημα της επιτάχυνσης της διέλευσης ενός δικτυακού σαρωτή για το άνοιγμα μιας προκαθορισμένης λίστας θυρών και το απλό ping των αντικειμένων δικτύου έχει αρχίσει να τίθεται εδώ και καιρό. Εδώ, βέβαια, η πρώτη λύση που έρχεται στο μυαλό είναι το multithreading. Δεδομένου ότι ο κύριος χρόνος που αφιερώνεται στο ping είναι η αναμονή για την επιστροφή του πακέτου και το επόμενο ping δεν μπορεί να ξεκινήσει μέχρι να επιστραφεί το προηγούμενο πακέτο, σε εταιρείες που είχαν ακόμη και 20+ διακομιστές συν εξοπλισμό δικτύου, αυτό λειτουργούσε ήδη αρκετά αργά. Το θέμα είναι ότι ένα πακέτο μπορεί να εξαφανιστεί, αλλά μην ειδοποιήσετε αμέσως τον διαχειριστή του συστήματος σχετικά. Απλώς θα σταματήσει να δέχεται τέτοια ανεπιθύμητα μηνύματα πολύ γρήγορα. Αυτό σημαίνει ότι πρέπει να κάνετε ping σε κάθε αντικείμενο περισσότερες από μία φορές πριν βγάλετε ένα συμπέρασμα σχετικά με την απροσπέλαστη. Χωρίς να υπεισέλθουμε σε πολλές λεπτομέρειες, είναι απαραίτητο να το παραλληλίσουμε γιατί αν δεν γίνει αυτό, τότε πιθανότατα ο διαχειριστής του συστήματος θα μάθει για το πρόβλημα από τον πελάτη και όχι από το σύστημα παρακολούθησης.
Η ίδια η PHP δεν υποστηρίζει multithreading out of the box. Με δυνατότητα πολλαπλής επεξεργασίας, μπορείτε να διαχωρίσετε. Αλλά, στην πραγματικότητα, είχα ήδη γραμμένο έναν μηχανισμό δημοσκόπησης και ήθελα να τον κάνω έτσι ώστε κάποτε να μετρήσω όλους τους κόμβους που χρειαζόμουν από τη βάση δεδομένων, να κάνω ping τα πάντα ταυτόχρονα, να περιμένω απάντηση από τον καθένα και μόνο μετά να γράφω αμέσως τα δεδομένα. Αυτό εξοικονομεί τον αριθμό των αιτημάτων ανάγνωσης. Το Multithreading ταιριάζει απόλυτα σε αυτήν την ιδέα. Για την PHP υπάρχει μια λειτουργική μονάδα PThreads που σας επιτρέπει να κάνετε πραγματικό multithreading, αν και χρειάστηκε αρκετός χρόνος για να το ρυθμίσετε στην PHP 7.2, αλλά έγινε. Η σάρωση θύρας και το ping είναι πλέον γρήγορα. Και αντί, για παράδειγμα, 15 δευτερόλεπτα ανά γύρο νωρίτερα, αυτή η διαδικασία άρχισε να διαρκεί 2 δευτερόλεπτα. Ήταν ένα καλό αποτέλεσμα.
Γρήγορος έλεγχος νέων εταιρειών
Πώς προέκυψε η λειτουργικότητα για τη συλλογή διαφόρων μετρήσεων και χαρακτηριστικών υλικού; Είναι απλό. Μερικές φορές απλά μας δίνουν εντολή να ελέγξουμε την τρέχουσα υποδομή πληροφορικής. Λοιπόν, το ίδιο πράγμα είναι απαραίτητο για να επιταχυνθεί ο έλεγχος ενός νέου πελάτη. Χρειαζόμασταν κάτι που θα μας επέτρεπε να έρθουμε σε μια μεσαία ή μεγάλη εταιρεία και να καταλάβουμε γρήγορα τι έχουν. Κατά τη γνώμη μου, το ping στο εσωτερικό δίκτυο μπλοκάρεται μόνο από εκείνους που θέλουν να περιπλέξουν τη ζωή τους, και από την εμπειρία μας υπάρχουν λίγοι από αυτούς. Υπάρχουν όμως και τέτοιοι άνθρωποι. Αντίστοιχα, μπορείτε να σαρώσετε γρήγορα δίκτυα για την παρουσία συσκευών με ένα απλό ping. Στη συνέχεια μπορούμε να τα προσθέσουμε και να κάνουμε σάρωση για ανοιχτές θύρες που μας ενδιαφέρουν. Στην πραγματικότητα, αυτή η λειτουργία υπήρχε ήδη· ήταν απαραίτητο μόνο να προσθέσετε μια εντολή από τον κεντρικό διακομιστή στον υποτελή, ώστε να σαρώσει τα καθορισμένα δίκτυα και να προσθέσει όλα όσα βρήκε στη λίστα. Ξέχασα να αναφέρω, υποτίθεται ότι είχαμε ήδη μια έτοιμη εικόνα με ένα διαμορφωμένο σύστημα (slave monitoring server) που θα μπορούσαμε απλά να το ξεδιπλώσουμε από τον πελάτη κατά τη διάρκεια ενός ελέγχου και να το συνδέσουμε στο cloud μας.
Αλλά το αποτέλεσμα ενός ελέγχου περιλαμβάνει συνήθως μια δέσμη διαφορετικών πληροφοριών, και μία από αυτές είναι τι είδους συσκευές υπάρχουν στο δίκτυο. Πρώτα απ 'όλα, μας ενδιέφεραν οι διακομιστές Windows και οι σταθμοί εργασίας των Windows ως μέρος ενός τομέα. Δεδομένου ότι στις μεσαίες και μεγάλες εταιρείες η έλλειψη domain είναι μάλλον εξαίρεση στον κανόνα. Για να μιλάς μια γλώσσα, ο μέσος όρος, κατά τη γνώμη μου, είναι 100+ άτομα. Ήταν απαραίτητο να βρούμε έναν τρόπο συλλογής δεδομένων από όλα τα μηχανήματα και τους διακομιστές των Windows, γνωρίζοντας το λογαριασμό IP και τον διαχειριστή τομέα τους, αλλά χωρίς να εγκαταστήσετε κανένα λογισμικό σε καθένα από αυτά. Η διεπαφή WMI έρχεται στη διάσωση. Windows Management Instrumentation (WMI) κυριολεκτικά σημαίνει εργαλεία διαχείρισης των Windows. Το WMI είναι μία από τις βασικές τεχνολογίες για κεντρική διαχείριση και παρακολούθηση της λειτουργίας διαφόρων τμημάτων της υποδομής υπολογιστών που εκτελούν την πλατφόρμα Windows. Λήψη από το wiki. Έπειτα, χρειάστηκε να τσιμπήσω ξανά για να μεταγλωττίσω το wmic (αυτός είναι ένας πελάτης WMI) για το Debian. Αφού όλα ήταν έτοιμα, το μόνο που έμενε ήταν απλά να ψηφίσουμε τους απαραίτητους κόμβους μέσω του wmic για τις απαραίτητες πληροφορίες. Μέσω του WMI μπορείτε να λάβετε σχεδόν οποιαδήποτε πληροφορία από έναν υπολογιστή με Windows και, επιπλέον, μπορείτε επίσης να ελέγξετε τον υπολογιστή μέσω αυτού, για παράδειγμα, να τον στείλετε για επανεκκίνηση. Έτσι εμφανίστηκε η συλλογή πληροφοριών για σταθμούς και διακομιστές Windows στο σύστημά μας. Επιπλέον, υπήρχαν τρέχουσες πληροφορίες σχετικά με τους τρέχοντες δείκτες φόρτου συστήματος. Τους ζητάμε πιο συχνά και πληροφορίες για το υλικό λιγότερο συχνά. Μετά από αυτό, ο έλεγχος έγινε λίγο πιο ευχάριστος.
Απόφαση διανομής λογισμικού
Εμείς οι ίδιοι χρησιμοποιούμε το σύστημα καθημερινά και είναι πάντα ανοιχτό για κάθε τεχνικό υπάλληλο. Και σκεφτήκαμε ότι θα μπορούσαμε να μοιραστούμε με άλλους αυτό που ήδη έχουμε. Το σύστημα δεν ήταν ακόμη έτοιμο για διανομή. Χρειάστηκε να επεξεργαστούν πολλά ώστε η τοπική έκδοση να μετατραπεί σε SaaS. Αυτές περιλαμβάνουν αλλαγές σε διάφορες τεχνικές πτυχές του συστήματος (απομακρυσμένες συνδέσεις, υπηρεσία υποστήριξης), ανάλυση μονάδων για αδειοδότηση, κοινή χρήση βάσεων δεδομένων πελατών, κλιμάκωση κάθε υπηρεσίας και ανάπτυξη συστημάτων αυτόματης ενημέρωσης για όλα τα μέρη. Αλλά αυτό θα είναι το δεύτερο μέρος του άρθρου.
Ενημέρωση
Πηγή: www.habr.com