Flexiant Cloud Orchestrator: με τι τρώγεται

Flexiant Cloud Orchestrator: με τι τρώγεται

Για να παρέχουμε υπηρεσίες IaaS (Virtual Data Center), εμείς Ρωσόνυξ χρησιμοποιούμε εμπορικό ενορχηστρωτή Flexiant Cloud Orchestrator (FCO). Αυτή η λύση έχει μια μάλλον μοναδική αρχιτεκτονική, η οποία τη διακρίνει από το Openstack και το CloudStack, γνωστά στο ευρύ κοινό.

Τα KVM, VmWare, Xen, Virtuozzo6/7, καθώς και κοντέινερ από το ίδιο Virtuozzo υποστηρίζονται ως υπερεπόπτες κόμβων υπολογιστών. Οι υποστηριζόμενες επιλογές αποθήκευσης περιλαμβάνουν τοπική αποθήκευση, NFS, Ceph και Virtuozzo Storage.

Το FCO υποστηρίζει τη δημιουργία και τη διαχείριση πολλαπλών συμπλεγμάτων από μια ενιαία διεπαφή. Δηλαδή, μπορείτε να διαχειριστείτε ένα σύμπλεγμα Virtuozzo και ένα σύμπλεγμα KVM + Ceph κάνοντας εναλλαγή μεταξύ τους με ένα κλικ του ποντικιού.

Στον πυρήνα του, το FCO είναι μια ολοκληρωμένη λύση για παρόχους cloud, η οποία, εκτός από την ενορχήστρωση, περιλαμβάνει και χρέωση, με όλες τις ρυθμίσεις, πρόσθετα πληρωμής, τιμολόγια, ειδοποιήσεις, μεταπωλητές, τιμολόγια κ.λπ. Ωστόσο, το τμήμα τιμολόγησης δεν είναι ικανό να καλύψει όλες τις ρωσικές αποχρώσεις, επομένως εγκαταλείψαμε τη χρήση του υπέρ μιας άλλης λύσης.

Είμαι πολύ ευχαριστημένος με το ευέλικτο σύστημα διανομής δικαιωμάτων σε όλους τους πόρους του cloud: εικόνες, δίσκους, προϊόντα, διακομιστές, τείχη προστασίας - όλα αυτά μπορούν να «κοινοποιηθούν» και να παραχωρηθούν δικαιώματα μεταξύ χρηστών, ακόμη και μεταξύ χρηστών διαφορετικών πελατών. Κάθε πελάτης μπορεί να δημιουργήσει πολλά ανεξάρτητα κέντρα δεδομένων στο cloud του και να τα διαχειρίζεται από έναν ενιαίο πίνακα ελέγχου.

Flexiant Cloud Orchestrator: με τι τρώγεται

Αρχιτεκτονικά, το FCO αποτελείται από πολλά μέρη, καθένα από τα οποία έχει τον δικό του ανεξάρτητο κώδικα και μερικά έχουν τη δική τους βάση δεδομένων.

Γραμμή ορίζοντα – διαχειριστής και διεπαφή χρήστη
Νεφρίτης – επιχειρηματική λογική, τιμολόγηση, διαχείριση εργασιών
Τιγρέλι – συντονιστής υπηρεσιών, διαχειρίζεται και συντονίζει την ανταλλαγή πληροφοριών μεταξύ επιχειρηματικής λογικής και συμπλεγμάτων.
XVPManager – διαχείριση στοιχείων συμπλέγματος: κόμβοι, αποθήκευση, δίκτυο και εικονικές μηχανές.
XVPAgent – ένας πράκτορας εγκατεστημένος σε κόμβους για αλληλεπίδραση με το XVPManager

Flexiant Cloud Orchestrator: με τι τρώγεται

Σκοπεύουμε να συμπεριλάβουμε μια λεπτομερή ιστορία για την αρχιτεκτονική κάθε στοιχείου σε μια σειρά άρθρων, εάν, φυσικά, το θέμα προκαλεί ενδιαφέρον.

Το κύριο πλεονέκτημα του FCO πηγάζει από την «εγκιβωτισμένη» φύση του. Η απλότητα και ο μινιμαλισμός είναι στη διάθεσή σας. Για τον κόμβο ελέγχου, εκχωρείται μια εικονική μηχανή στο Ubuntu, στην οποία είναι εγκατεστημένα όλα τα απαραίτητα πακέτα. Όλες οι ρυθμίσεις τοποθετούνται σε αρχεία διαμόρφωσης με τη μορφή τιμής μεταβλητής:

# cat /etc/extility/config/vars
…
export LIMIT_MAX_LIST_ADMIN_DEFAULT="30000"
export LIMIT_MAX_LIST_USER_DEFAULT="200"
export LOGDIR="/var/log/extility"
export LOG_FILE="misc.log"
export LOG_FILE_LOG4JHOSTBILLMODULE="hostbillmodule.log"
export LOG_FILE_LOG4JJADE="jade.log"
export LOG_FILE_LOG4JTL="tigerlily.log"
export LOG_FILE_LOG4JXVP="xvpmanager.log"
export LOG_FILE_VARS="misc.log"
…

Ολόκληρη η διαμόρφωση αρχικά επεξεργάζεται σε πρότυπα και στη συνέχεια εκκινείται η γεννήτρια
#build-config που θα δημιουργήσει ένα αρχείο vars και θα δώσει εντολή στις υπηρεσίες να διαβάσουν ξανά τη διαμόρφωση. Η διεπαφή χρήστη είναι ωραία και μπορεί εύκολα να χαρακτηριστεί.

Flexiant Cloud Orchestrator: με τι τρώγεται

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

Παρά την κλειστή φύση του, το FCO είναι ένα εξαιρετικά προσαρμόσιμο σύστημα. Έχει έναν τεράστιο αριθμό ρυθμίσεων και σημείων εισόδου για την αλλαγή της ροής εργασίας:

  1. Υποστηρίζονται προσαρμοσμένες προσθήκες, για παράδειγμα, μπορείτε να γράψετε τη δική σας μέθοδο χρέωσης ή τον δικό σας εξωτερικό πόρο για να παρέχετε στον χρήστη
  2. Υποστηρίζονται προσαρμοσμένοι κανόνες ετικέτας για ορισμένα συμβάντα, για παράδειγμα, η προσθήκη της πρώτης εικονικής μηχανής σε έναν πελάτη κατά τη δημιουργία του
  3. Υποστηρίζονται προσαρμοσμένα γραφικά στοιχεία στη διεπαφή, για παράδειγμα, η ενσωμάτωση ενός βίντεο YouTube απευθείας στη διεπαφή χρήστη.

Όλες οι προσαρμογές είναι γραμμένες σε FDL, το οποίο βασίζεται στο Lua. Εάν γνωρίζετε τον Lua, δεν θα υπάρχουν προβλήματα με το FDL.

Ακολουθεί ένα παράδειγμα ενός από τους απλούστερους ενεργοποιητές που χρησιμοποιούμε. Αυτό το έναυσμα δεν επιτρέπει στους χρήστες να μοιράζονται τις δικές τους εικόνες με άλλους πελάτες. Αυτό το κάνουμε για να εμποδίσουμε έναν χρήστη να δημιουργήσει μια κακόβουλη εικόνα για άλλους χρήστες.

function register()
    return {"pre_user_api_publish"}
end
   
function pre_user_api_publish(p)  
    if(p==nil) then
        return{
            ref = "cancelPublishImage",
            name = "Cancel publishing",
            description = "Cancel all user’s images publishing",
            triggerType = "PRE_USER_API_CALL",
            triggerOptions = {"publishResource", "publishImage"},
            api = "TRIGGER",
            version = 1,
        }
    end

    -- Turn publishing off
    return {exitState = "CANCEL"}
   
end

Η συνάρτηση καταχωρητή θα κληθεί από τον πυρήνα FCO. Θα επιστρέψει το όνομα της συνάρτησης που θα κληθεί. Η παράμετρος "p" αυτής της συνάρτησης αποθηκεύει το πλαίσιο κλήσης και την πρώτη φορά που θα κληθεί θα είναι κενό (μηδέν). Κάτι που θα μας επιτρέψει να καταχωρήσουμε την σκανδάλη μας. Στο triggerType υποδεικνύουμε ότι το έναυσμα ενεργοποιείται ΠΡΙΝ από τη λειτουργία δημοσίευσης και επηρεάζει μόνο τους χρήστες. Φυσικά, επιτρέπουμε στους διαχειριστές συστήματος να δημοσιεύουν τα πάντα. Στο triggerOptions περιγράφουμε λεπτομερώς τις λειτουργίες για τις οποίες θα ενεργοποιηθεί η σκανδάλη.

Και το κυριότερο είναι η επιστροφή {exitState = "CANCEL"}, γι' αυτό αναπτύχθηκε το έναυσμα. Θα επιστρέψει αποτυχία όταν ο χρήστης προσπαθήσει να μοιραστεί την εικόνα του στον πίνακα ελέγχου.

Στην αρχιτεκτονική FCO, οποιοδήποτε αντικείμενο (δίσκος, διακομιστής, εικόνα, δίκτυο, προσαρμογέας δικτύου, κ.λπ.) αναπαρίσταται ως οντότητα πόρων, η οποία έχει κοινές παραμέτρους:

  • UUID πόρων
  • όνομα πόρου
  • τύπος πόρου
  • UUID κατόχου πόρων
  • κατάσταση πόρων (ενεργός, ανενεργός)
  • μεταδεδομένα πόρων
  • κλειδιά πόρων
  • UUID του προϊόντος που κατέχει τον πόρο
  • πόρος VDC

Αυτό είναι πολύ βολικό όταν εργάζεστε χρησιμοποιώντας ένα API, όταν όλοι οι πόροι εργάζονται σύμφωνα με την ίδια αρχή. Τα προϊόντα διαμορφώνονται από τον πάροχο και παραγγέλλονται από τον πελάτη. Δεδομένου ότι η χρέωσή μας είναι στο πλάι, ο πελάτης μπορεί ελεύθερα να παραγγείλει οποιοδήποτε προϊόν από τον πίνακα. Θα υπολογιστεί αργότερα στη τιμολόγηση. Το προϊόν μπορεί να είναι μια διεύθυνση IP ανά ώρα, ένα επιπλέον GB δίσκου ανά ώρα ή απλώς ένας διακομιστής.

Τα κλειδιά μπορούν να χρησιμοποιηθούν για την επισήμανση ορισμένων πόρων για να αλλάξει η λογική της εργασίας μαζί τους. Για παράδειγμα, μπορούμε να επισημάνουμε τρεις φυσικούς κόμβους με το κλειδί Weight και να επισημάνουμε ορισμένους πελάτες με το ίδιο κλειδί, εκχωρώντας έτσι αυτούς τους κόμβους προσωπικά σε αυτούς τους πελάτες. Χρησιμοποιούμε αυτόν τον μηχανισμό για VIP πελάτες που δεν τους αρέσουν οι γείτονες δίπλα στα VM τους. Η ίδια η λειτουργικότητα μπορεί να χρησιμοποιηθεί πολύ ευρύτερα.

Το μοντέλο αδειοδότησης περιλαμβάνει την πληρωμή για κάθε πυρήνα επεξεργαστή ενός φυσικού κόμβου. Το κόστος επηρεάζεται επίσης από τον αριθμό των τύπων συστάδων. Εάν σκοπεύετε να χρησιμοποιήσετε μαζί το KVM και το VMware, για παράδειγμα, το κόστος της άδειας χρήσης θα αυξηθεί.

Το FCO είναι ένα πλήρες προϊόν, η λειτουργικότητά του είναι πολύ πλούσια, επομένως σχεδιάζουμε να ετοιμάσουμε πολλά άρθρα ταυτόχρονα με λεπτομερή περιγραφή της λειτουργίας του τμήματος δικτύου.

Έχοντας συνεργαστεί με αυτόν τον ενορχηστρωτή για αρκετά χρόνια, μπορούμε να τον χαρακτηρίσουμε ως πολύ κατάλληλο. Δυστυχώς, το προϊόν δεν είναι χωρίς ελαττώματα:

  • έπρεπε να βελτιστοποιήσουμε τη βάση δεδομένων επειδή τα ερωτήματα άρχισαν να επιβραδύνονται καθώς αυξανόταν ο όγκος των δεδομένων σε αυτά.
  • Μετά από ένα ατύχημα, ο μηχανισμός ανάκτησης δεν λειτούργησε λόγω σφάλματος και έπρεπε να ανακτήσουμε τα αυτοκίνητα ατυχών πελατών χρησιμοποιώντας το δικό μας σύνολο σεναρίων.
  • Ο μηχανισμός για τον εντοπισμό της μη διαθεσιμότητας κόμβου είναι ενσωματωμένος στον κώδικα και δεν μπορεί να προσαρμοστεί. Δηλαδή, δεν μπορούμε να δημιουργήσουμε τις δικές μας πολιτικές για τον προσδιορισμό της μη διαθεσιμότητας ενός κόμβου.
  • Η καταγραφή δεν είναι πάντα λεπτομερής. Μερικές φορές, όταν χρειάζεται να κατεβείτε σε πολύ χαμηλό επίπεδο για να κατανοήσετε ένα συγκεκριμένο πρόβλημα, δεν έχετε αρκετό πηγαίο κώδικα ώστε ορισμένα στοιχεία να καταλάβουν γιατί.

ΣΥΝΟΛΟ: Σε γενικές γραμμές, οι εντυπώσεις από το προϊόν είναι καλές. Είμαστε σε συνεχή επαφή με τους προγραμματιστές ενορχηστρωτή. Τα παιδιά είναι διατεθειμένα για εποικοδομητική συνεργασία.

Παρά την απλότητά του, το FCO έχει ευρεία λειτουργικότητα. Σε μελλοντικά άρθρα σκοπεύουμε να εμβαθύνουμε στα ακόλουθα θέματα:

  • δικτύωση στο FCO
  • παρέχοντας πρωτόκολλο ζωντανής ανάκτησης και FQP
  • γράφοντας τα δικά σας πρόσθετα και γραφικά στοιχεία
  • συνδέοντας πρόσθετες υπηρεσίες όπως το Load Balancer και το Acronis
  • αντιγράφων ασφαλείας
  • ενοποιημένος μηχανισμός για τη διαμόρφωση και τη διαμόρφωση κόμβων
  • επεξεργασία μεταδεδομένων εικονικής μηχανής

ZY Γράψτε στα σχόλια αν σας ενδιαφέρουν άλλες πτυχές. Μείνετε συντονισμένοι!

Πηγή: www.habr.com

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