Αποποίηση ευθυνών

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

Αυτές οι Συχνές Ερωτήσεις απαντούν σε συνήθεις ερωτήσεις για τον τρόπο με τον οποίο η Oracle προσφέρει ανθεκτικότητα και αδιάκοπη διαθεσιμότητα στις κύριες υπηρεσίες υποδομής και την πλατφόρμα φιλοξενίας της. Οι πελάτες του Oracle Cloud μπορεί να ενδιαφέρονται για αυτές τις απαντήσεις για διάφορους λόγους:

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

Συχνές Ερωτήσεις για την ανθεκτικότητα και την αδιάκοπη διαθεσιμότητα των υπηρεσιών και της πλατφόρμας του Oracle Cloud Infrastructure

Διαχωρίζει η Oracle τις διαφορετικές κλάσεις υπηρεσιών όπως τις κρίσιμες υπηρεσίες, τις υπηρεσίες αδιάκοπης διαθεσιμότητας ή τις υπηρεσίες μίας τοποθεσίας;

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

Επίπεδα εξάρτησης

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

Από κάτω προς τα επάνω:

  • Κύριες υπηρεσίες: Αυτές οι υπηρεσίες αποτελούν τη βάση του Oracle Cloud Infrastructure. Περιλαμβάνουν τις υπηρεσίες Identity and Access Management (IAM), Key Management, Networking, Compute, Block Volumes, Object Storage, Telemetry και διάφορες άλλες κοινόχρηστες εσωτερικές υπηρεσίες. Έχουν σχεδιαστεί έτσι ώστε να έχουν ελάχιστες εξαρτήσεις, ακόμη και μεταξύ τους. (Παρακάτω σε αυτό το έγγραφο μπορείτε να βρείτε λεπτομέρειες σχετικά με τις εξαρτήσεις).
  • IaaS: Αυτό το επίπεδο παρέχει περισσότερη λειτουργικότητα σε επίπεδο υποδομής, η οποία βασίζεται στον πυρήνα του συστήματος. Σε αυτό το επίπεδο συμπεριλαμβάνονται οι υπηρεσίες File Storage, Database και Container Engine for Kubernetes.
  • SaaS: Αυτό το επίπεδο είναι εμπλουτισμένο λογισμικό ως υπηρεσία, το οποίο βασίζεται σε χαμηλότερα επίπεδα.
Εμβέλεια διαθεσιμότητας

Για την εκπλήρωση των στόχων διαθεσιμότητας και ανθεκτικότητας μιας υπηρεσίας, επιλέγεται μία από τις ακόλουθες εμβέλειες διαθεσιμότητας για κάθε υπηρεσία:

  • Τοπικός τομέας διαθεσιμότητας: Κάθε τομέας διαθεσιμότητας περιέχει ένα ανεξάρτητο στιγμιότυπο της υπηρεσίας. Αυτές οι υπηρεσίες προσφέρουν υψηλή ανθεκτικότητα για τα αποθηκευμένα δεδομένα, χρησιμοποιώντας σύγχρονη αναπαραγωγή μεταξύ των αντιγράφων εντός του ίδιου τομέα διαθεσιμότητας (για λεπτομέρειες, δείτε παρακάτω τη σχετική ενότητα για τους τομείς σφαλμάτων). Αυτές οι υπηρεσίες είναι ανθεκτικές σε διακοπές λειτουργίας τουλάχιστον του ενός τρίτου της υποδομής στον τομέα διαθεσιμότητας, ανάλογα με τη φύση της υπηρεσίας. Οι τοπικές υπηρεσίες τομέα διαθεσιμότητας πετυχαίνουν αυτό το επίπεδο ανθεκτικότητας σε σφάλματα, χρησιμοποιώντας δύο διαφορετικά κέντρα λογικών δεδομένων —λογικές ομάδες απομόνωσης σφαλμάτων και απόδοσης— εντός του τομέα διαθεσιμότητας. Για λεπτομέρειες, δείτε τις ενότητες σχετικά με τους τομείς σφαλμάτων και τα κελιά υπηρεσιών σε αυτό το έγγραφο. Τέλος, αυτές οι υπηρεσίες μπορούν να συνεχίσουν να λειτουργούν κανονικά, ακόμη και αν ο τομέας διαθεσιμότητας δεν μπορεί να επικοινωνήσει με άλλους τομείς διαθεσιμότητας. Ως αποτέλεσμα, απορροφούν την απώλεια των άλλων τομέων διαθεσιμότητας ή ολόκληρη την αποτυχία του δικτύου ευρείας περιοχής εντός της περιοχής.
  • Πολλοί τομείς διαθεσιμότητας περιοχής: Κάθε περιοχή με πολλούς τομείς διαθεσιμότητας περιέχει ένα ανεξάρτητο στιγμιότυπο της υπηρεσίας, με συστατικά στοιχεία σε κάθε τομέα διαθεσιμότητας στην περιοχή. Αυτές οι υπηρεσίες προσφέρουν εξαιρετικά υψηλή ανθεκτικότητα για τα αποθηκευμένα δεδομένα, χρησιμοποιώντας σύγχρονη αναπαραγωγή σε πολλούς τομείς διαθεσιμότητας στην ίδια περιοχή. Οι υπηρεσίες αυτές είναι ανθεκτικές σε διακοπές λειτουργίας ή στην αδυναμία επικοινωνίας ενός μόνο τομέα διαθεσιμότητας στην περιοχή.
  • Ένας μοναδικός τομέας διαθεσιμότητας περιοχής: Αν μια περιοχή περιέχει μόνο έναν μοναδικό τομέα διαθεσιμότητας, τα ορατά χαρακτηριστικά μιας υπηρεσίας περιοχής αντιστοιχούν σε αυτά μιας τοπικής υπηρεσίας τομέα διαθεσιμότητας, όπως περιγράφεται παραπάνω. Η διαφορά μεταξύ μιας τοπικής υπηρεσίας τομέα διαθεσιμότητας και μιας υπηρεσίας περιοχής ενός τομέα διαθεσιμότητας έχει σημασία μόνο όταν μια περιοχή ενός μοναδικού τομέα διαθεσιμότητας επεκταθεί με την προσθήκη ενός ή περισσότερων τομέων διαθεσιμότητας. Όταν συμβαίνει αυτό, κάθε υπηρεσία περιοχής επεκτείνεται αυτόματα ώστε να αξιοποιήσει κατάλληλα τους νέους τομείς διαθεσιμότητας, παραμένοντας ως μοναδικό στιγμιότυπο της υπηρεσίας. Για παράδειγμα, το επίπεδο δεδομένων της υπηρεσίας Object Storage θα επεκταθεί έτσι ώστε να χρησιμοποιήσει τους επιπλέον τομείς διαθεσιμότητας και να βελτιώσει την ανθεκτικότητα των υπαρχόντων δεδομένων. Αντιθέτως, για τις τοπικές υπηρεσίες τομέα διαθεσιμότητας, καθένας από τους νέους τομείς διαθεσιμότητας λαμβάνει ένα δικό του νέο και ξεχωριστό στιγμιότυπο για κάθε τοπική υπηρεσία τομέα διαθεσιμότητας.
  • Διανομή σε διαφορετικές περιοχές: Μια θεμελιώδης αρχή του Oracle Cloud Infrastructure είναι ότι κάθε περιοχή είναι όσο το δυνατόν περισσότερο λειτουργικά ανεξάρτητη από άλλες περιοχές. Η προϋπόθεση όσο το δυνατόν αντικατοπτρίζει το γεγονός ότι οι περιοχές πρέπει οπωσδήποτε να μοιράζονται έστω και ένα μικρό μέρος της υποδομής, για παράδειγμα, το δίκτυο υποδομής μεταξύ περιοχών. Σε κάθε περίπτωση, δεν δημιουργούμε μηχανισμούς κλειστής ζεύξης μεταξύ περιοχών, όπως διαφανή υψηλή διαθεσιμότητα ή ανακατεύθυνση, η οποία θα μπορούσε να δημιουργήσει προβλήματα που επηρεάζουν πολλές περιοχές ταυτόχρονα. Αντιθέτως, παρέχουμε δύο μηχανισμούς για τη διανομή υπηρεσιών σε περιοχές με εύκαμπτη ζεύξη:
    • Ανάκτηση μετά από καταστροφή (DR): Η δυνατότητα που παρέχουμε στους πελάτες μας να δημιουργούν συστήματα με χαρακτηριστικά DR αποτελεί ακρογωνιαίο λίθο της προσέγγισης και επένδυσής μας στο cloud. Αρκετές κύριες υπηρεσίες προσφέρουν ήδη μηχανισμούς DR —για παράδειγμα, η δημιουργία εφεδρικών αντιγράφων μεταξύ περιοχών της υπηρεσίας Block Volumes και η αντιγραφή μεταξύ περιοχών της υπηρεσίας Object Storage. Η ενσωμάτωση λειτουργικότητας DR σε όλες οι υπηρεσίες μας αποτελεί υψηλή προτεραιότητα για εμάς.
    • Συνδρομές εντός περιοχών: Προς το παρόν, παρέχουμε συνδρομές εντός περιοχών μόνο για δεδομένα IAM. Από εννοιολογική άποψη, τα δεδομένα IAM έχουν καθολική εμβέλεια. Οι πελάτες μπορούν να εγγραφούν (opt-in) σε ένα σύνολο περιοχών και εμείς αναπαράγουμε αυτόματα τα σχετικά δεδομένα IAM και τις επόμενες ενημερώσεις στις συγκεκριμένες περιοχές. Για να αποφευχθεί η κλειστή ζεύξη, η αναπαραγωγή γίνεται ασύγχρονα και σταδιακά συνεπής. Οι πελάτες πραγματοποιούν τροποποιήσεις στα δεδομένα IAM τους στην "αρχική" περιοχή που ορίζουν. Αν η τρέχουσα αρχική περιοχή δεν είναι πλέον διαθέσιμη ή είναι ακατάλληλη για κάποιον λόγο, οι πελάτες μπορούν ορίσουν μια διαφορετική περιοχή.
Επίπεδο ελέγχου σε σχέση με το επίπεδο δεδομένων

Το επίπεδο δεδομένων μιας υπηρεσίας είναι η συλλογή των διασυνδέσεων και συστατικών στοιχείων επεξεργασίας δεδομένων που υλοποιούν τη λειτουργικότητα της υπηρεσίας, η οποία προορίζεται για χρήση από τις εφαρμογές. Για παράδειγμα, το επίπεδο δεδομένων του εικονικού δικτύου cloud (VCN) περιλαμβάνει το σύστημα επεξεργασίας πακέτων δικτύου, εικονικούς δρομολογητές και πύλες, ενώ το επίπεδο δεδομένων της υπηρεσίας Block Volumes περιλαμβάνει την υλοποίηση του πρωτοκόλλου iSCSI και το σύστημα χώρου αποθήκευσης με ανοχή στα σφάλματα που έχει αναπαραχθεί για δεδομένα τόμου.

Το επίπεδο ελέγχου μιας υπηρεσίας είναι το σύνολο API και συστατικών στοιχείων που είναι υπεύθυνα για τις ακόλουθες εργασίες:

  • Τον χειρισμό των αιτημάτων πελατών για παροχή, επαναδιαμόρφωση, επέκταση/περιορισμό ή τερματισμό των πόρων
  • Την εκτέλεση αυτοματοποιημένης επιδιόρθωσης μεγάλων στόλων με ταχύτητα και ασφάλεια
  • Τον εντοπισμό πόρων που έχουν αποτύχει, υποβαθμιστεί ή διαμορφωθεί εσφαλμένα
  • Την εκτέλεση αυτοματοποιημένης επισκευής ή την ειδοποίηση ειδικών ατόμων για βοήθεια
  • Τη συνεργασία με άλλα επίπεδα ελέγχου (π.χ. οι υπηρεσίες Compute, VCN, Block Storage συνδυάζονται κατά τη διάρκεια της διεργασίας LaunchInstance)
  • Τη διαχείριση δυναμικότητας που δεν χρησιμοποιείται
  • Τον συντονισμό με ανθρώπους, για παράδειγμα, κατά την άφιξη νέου εξοπλισμού και για φυσικές επισκευές και συντήρηση
  • Την παροχή λειτουργικής ορατότητας και ελέγχου
 
 

Πώς διασφαλίζει η Oracle ότι οι υπηρεσίες είναι ανθεκτικές και διαθέσιμες αδιάκοπα;

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

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

Παραδοσιακά, η ανάλυση της διαθεσιμότητας των εταιρικών συστημάτων ΙΤ εστιάζει στην κατηγορία της αστοχίας υλικού. Ωστόσο, για τα συστήματα cloud, η αστοχία υλικού είναι ένα σχετικά μικρό και καλά τεκμηριωμένο πρόβλημα. Είναι πλέον αρκετά εύκολο να αποφύγετε ή να μετριάσετε τα μοναδικά σημεία αστοχίας υλικού. Για παράδειγμα, τα rack μπορούν να έχουν διπλή τροφοδοσία ρεύματος και αντίστοιχο αριθμό μονάδων διανομής ενώ πολλά συστατικά στοιχεία έχουν δυνατότητα εναλλαγής εν ενεργεία (hot-swappable). Φυσικά, πάντα υπάρχει η πιθανότητα μιας μεγάλης αστοχίας υλικού, για παράδειγμα, εξαιτίας μιας φυσικής καταστροφής. Ωστόσο, σύμφωνα με την εμπειρία μας και με αναφορές από δημόσιες επιθεωρήσεις άλλων προμηθευτών cloud, η αστοχία ή απώλεια ενός ολόκληρου κέντρου δεδομένων έχει ελάχιστες πιθανότητες να συμβεί σε σχέση με άλλες αιτίες μη διαθεσιμότητας. Βεβαίως, μια μεγάλη αστοχία υλικού είναι κάτι το οποίο πρέπει να αντιμετωπιστεί (για παράδειγμα, με ανάκτηση μετά από καταστροφή και άλλους μηχανισμούς), αλλά σε καμία περίπτωση δεν αποτελεί την κύρια αιτία μη διαθεσιμότητας.

Οι κύριες αιτίες μη διαθεσιμότητας σε συστήματα cloud είναι οι εξής:

  1. Σφάλματα λογισμικού
  2. Σφάλματα διαμόρφωσης
  3. Ανθρώπινα λάθη
    Σημείωση: Ο κλάδος μάς έχει δείξει ότι αυτοί οι τρεις τύποι ανθρώπινων λαθών είναι οι κυριότερες αιτίες μη διαθεσιμότητας με μεγάλη διαφορά. Παρόλο που η συχνότητά τους μπορεί να μειωθεί χρησιμοποιώντας εργαλεία, αυτοματισμό και εκπαίδευση, δεν μπορούν να εξαλειφθούν πλήρως. Επομένως, πρέπει να λαμβάνονται σοβαρά υπόψη στην αρχιτεκτονική, τη σχεδίαση και την υλοποίηση του συστήματος.
  4. Μη αποδεκτή μεταβολή στην απόδοση (καθυστέρηση ή ταχύτητα μετάδοσης) για οποιονδήποτε λόγο, συμπεριλαμβανομένων των ακόλουθων:
    • "Θορυβώδεις γείτονες" πολλαπλών εκμισθωτών (αποτυχία μηχανισμών QoS (ποιότητας υπηρεσίας ))
    • Αδυναμία απόρριψης υπερφόρτωσης (ακούσιας ή κακόβουλης) όσο συνεχίζετε να κάνετε χρήσιμες εργασίες
    • Διανομή λυγισμού μνήμης, καταιγισμός μηνυμάτων, καταιγισμός επαναλήψεων και άλλες δαπανηρές "αναδυόμενες" αλληλεπιδράσεις
    • Κενές κρυφές μνήμες μετά από απενεργοποίηση και εκ νέου ενεργοποίηση, συγκεκριμένα, ταυτόχρονη απενεργοποίηση και εκ νέου ενεργοποίηση πολλών συστημάτων
    • Επιβάρυνση κατά την κλιμάκωση του συστήματος (για παράδειγμα, κατακερματισμός δεδομένων εκ νέου)
  5. Αποτυχία περιορισμού της επίδρασης (ο αριθμός των πελατών και συστημάτων που επηρεάζονται) των ζητημάτων που αναφέρονται παραπάνω

Αυτές οι προκλήσεις είναι καθολικές — είναι μέρος των "νόμων της φυσικής" για τα διανεμημένα συστήματα cloud.

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

  • Αρχές σχεδίασης αρχιτεκτονικής και συστήματος
  • Νέες έννοιες αρχιτεκτονικής (οι οποίες συνήθως προκύπτουν από την εφαρμογή των αρχών)
  • Διαδικασίες μηχανικής υπηρεσιών
Αρχές σχεδίασης αρχιτεκτονικής και συστήματος

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

Υπολογιστική που εστιάζει στη δυνατότητα ανάκτησης

Για να αντιμετωπίσουμε τα σφάλματα λογισμικού και τα λάθη των χειριστών που έχουν σχετικά τοπική επίδραση, ακολουθούμε τις αρχές της υπολογιστικής που εστιάζει στη δυνατότητα ανάκτησης1. Σε υψηλό επίπεδο, αυτό σημαίνει ότι αντί να προσπαθούμε να εγγυηθούμε ότι δεν θα έχουμε ποτέ κάποιο πρόβλημα (το οποίο είναι αδύνατο να δοκιμαστεί), εστιάζουμε στη διακριτική αντιμετώπιση των προβλημάτων, με έναν τρόπο που μπορεί να δοκιμαστεί. Συγκεκριμένα, εστιάζουμε στην ελαχιστοποίηση του μέσου χρόνου ανάκτησης (MTTR), ο οποίος είναι ένας συνδυασμός των μέσων χρόνων εντοπισμού, διάγνωσης και μετριασμού.

Ο σκοπός μας είναι να πραγματοποιήσουμε μια ανάκτηση όσο το δυνατόν πιο γρήγορα, ώστε οι χρήστες να μην επηρεαστούν από το ζήτημα. Τα ακόλουθα σημεία μας βοηθούν να επιτύχουμε αυτόν τον στόχο:

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

Ελαχιστοποίηση των επιδράσεων που έχουν τα ζητήματα

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

Αρχιτεκτονικές έννοιες που προκύπτουν από τις αρχές σχεδίασης

Υπάρχουν πολλές τέτοιες έννοιες αλλά θα εστιάσουμε σε αυτές που σχετίζονται με τον περιορισμό της επίδρασης.

Έννοιες τοποθέτησης που περιλαμβάνονται στο δημόσιο API μας: Περιοχές, τομείς διαθεσιμότητας και τομείς σφαλμάτων

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

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

Η εγγύηση που παρέχουν είναι ότι σε έναν δεδομένο τομέα διαθεσιμότητας, τροποποιούνται πόροι σε έναν μόνο τομέα σφαλμάτων ανά πάσα στιγμή. Αν παρουσιαστεί κάποιο πρόβλημα με τη διαδικασία τροποποίησης, ορισμένοι ή όλοι οι πόροι στον τομέα σφαλμάτων μπορεί να μην είναι διαθέσιμοι για ένα μικρό χρονικό διάστημα, αλλά οι άλλοι τομείς σφαλμάτων στον τομέα διαθεσιμότητας δεν επηρεάζονται. Κάθε τομέας διαθεσιμότητας περιέχει τρεις τομείς σφαλμάτων, ώστε να επιτρέπεται η φιλοξενία των συστημάτων αναπαραγωγής βάσει διανεμημένης υπολογιστικής (για παράδειγμα, Oracle Data Guard) με υψηλή διαθεσιμότητα εντός ενός μόνο τομέα διαθεσιμότητας.

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

Επιπλέον, οι τομείς σφαλμάτων προστατεύουν από κάποιους τύπους τοπικής αστοχίας υλικού. Οι ιδιότητες των τομέων σφαλμάτων εγγυώνται ότι οι πόροι που τοποθετούνται σε διαφορετικούς τομείς σφαλμάτων δεν μοιράζονται πιθανά μοναδικά σημεία αστοχίας υλικού εντός του τομέα διαθεσιμότητας, στον μέγιστο δυνατό βαθμό. Για παράδειγμα, οι πόροι σε διαφορετικούς τομείς σφαλμάτων δεν μοιράζονται τον ίδιο διακόπτη δικτύου top-of-rack, επειδή η τυπική σχεδίαση αυτών των διακοπτών δεν διαθέτει εφεδρεία.

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

Οι εσωτερικές υπηρεσίες μας χρησιμοποιούν τους τομείς σφαλμάτων με τον ίδιο τρόπο που θα πρέπει να τους χρησιμοποιούν οι πελάτες. Για παράδειγμα, οι υπηρεσίες Block Volumes, Object Storage και File Storage αποθηκεύουν αντίγραφα των δεδομένων σε τρεις διαφορετικούς τομείς σφαλμάτων. Όλα τα συστατικά στοιχεία σε όλα τα επίπεδα ελέγχου και δεδομένων φιλοξενούνται και στους τρεις τομείς διαθεσιμότητας (ή σε πολλούς τομείς διαθεσιμότητας σε μια περιοχή που διαθέτει πολλούς τέτοιους τομείς).

Κελιά υπηρεσιών

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

Επιπλέον, τα κελιά υπηρεσιών περιορίζουν επίσης την επίδραση σε ορισμένα σπάνια αλλά περίπλοκα σενάρια στα οποία το σύστημα τροποποιείται ενεργά. Ένα κλασικό παράδειγμα είναι όταν η ανάπτυξη σε έναν μεμονωμένο τομέα σφαλμάτων εμφανίζεται ως επιτυχημένη χωρίς σφάλματα ή αλλαγές στην απόδοσή της. Ωστόσο, μόλις ενημερώνεται ο δεύτερος ή ο τελευταίος τομέας σφαλμάτων, οι νέες αλληλεπιδράσεις εντός του συστήματος (σε πλήρη κλίμακα cloud με φόρτο εργασίας παραγωγής) προκαλούν ένα ζήτημα απόδοσης.

Σημειώστε ότι η χρήση κελιών υπηρεσιών είναι ένα αρχιτεκτονικό μοτίβο και όχι μια έννοια που ονομάζεται ρητά στο API ή το SDK του Oracle Cloud. Οποιοδήποτε σύστημα πολλαπλών εκμισθωτών μπορεί να χρησιμοποιήσει αυτό το αρχιτεκτονικό μοτίβο και δεν απαιτεί υποστήριξη από την πλατφόρμα cloud.

Τα κελιά υπηρεσιών λειτουργούν ως εξής:

  • Κάθε στιγμιότυπο της υπηρεσίας (για παράδειγμα, σε μια συγκεκριμένη περιοχή ή έναν συγκεκριμένο τομέα διαθεσιμότητας για τοπικές υπηρεσίες τομέων διαθεσιμότητας) αποτελείται από πολλές ξεχωριστές αναπτύξεις της στοίβας λογισμικού της υπηρεσίας. Κάθε ξεχωριστή ανάπτυξη ονομάζεται κελί. Κάθε κελί φιλοξενείται σε δική του υποδομή, εφόσον είναι δυνατό. Σε κάθε περίπτωση, τα κελιά δεν μοιράζονται κεντρικούς ή εικονικούς υπολογιστές.
  • Μια υπηρεσία μπορεί αν ξεκινήσει με λίγα μόνο κελιά σε κάθε τομέα ή περιοχή διαθεσιμότητας. Καθώς η υπηρεσία κλιμακώνεται για να ικανοποιήσει την αυξανόμενη ζήτηση, προστίθενται περισσότερα κελιά για να περιοριστεί το μέγεθος της επίδρασης που έχουν τυχόν ζητήματα. Μια μεγάλη δημοφιλής υπηρεσία μπορεί να έχει πολλά κελιά. Με άλλα λόγια, τα κελιά βελτιώνουν την πολυπλεξία n-σε-m των φόρτων εργασίας πελατών σε ξεχωριστά περιβάλλοντα φιλοξενίας —ξεχωριστές νησίδες απομόνωσης πόρων. Τα κελιά δεν έχουν προφανή πληθικότητα όπως οι τομείς σφαλμάτων. (Όπως αναφέρθηκε παραπάνω, μια προφανής επιλογή για την πληθικότητα των τομέων σφαλμάτων είναι τρεις ανά τομέα διαθεσιμότητας ώστε να επιτρέπεται η φιλοξενία των συστημάτων αναπαραγωγής βάσει διανεμημένης υπολογιστικής με υψηλή διαθεσιμότητα εντός ενός μόνο τομέα διαθεσιμότητας.)
  • Κάθε "φυσική μονάδα" ενός φόρτου εργασίας πελάτη αντιστοιχίζεται σε ένα συγκεκριμένο κελί. Ο ορισμός της "φυσικής μονάδας" εξαρτάται από τη φύση της συγκεκριμένης υπηρεσίας. Για παράδειγμα, για την εσωτερική κοινόχρηστη υπηρεσία Workflow μας (περιγράφεται παρακάτω), the η φυσική μονάδα μπορεί να είναι "όλες οι ροές εργασίας σε αυτόν τον τομέα ή την περιοχή διαθεσιμότητας για ένα συγκεκριμένο επίπεδο ελέγχου."
  • Μπροστά από κάθε ομάδα κελιών υπάρχει ένα ελάχιστο επίπεδο δρομολόγησης ή ένα API για την ανακάλυψη των τελικών σημείων κελιών. Για παράδειγμα, το σύστημα Streaming/Messaging διαθέτει ένα API για να ανακαλύπτει το τρέχον τελικό σημείο του επιπέδου δεδομένων για ένα συγκεκριμένο θέμα και ο εσωτερικός χώρος αποθήκευσης μεταδεδομένων διαθέτει ένα ξεχωριστό τελικό σημείο ανά κελί. Ωστόσο, άλλες υπηρεσίες που βασίζονται σε κελιά διαθέτουν ένα μόνο τελικό σημείο επιπέδου δεδομένων και ένα κοινόχρηστο επίπεδο δρομολόγησης. Το επίπεδο δρομολόγησης είναι μια πιθανή αιτία συσχετισμένης αποτυχίας πολλών κελιών, αλλά αυτό μπορεί να μετριαστεί διατηρώντας το επίπεδο δρομολόγησης εξαιρετικό απλό, προβλέψιμο και αποδοτικό (χωρίς ακριβές λειτουργίες) και παρέχοντάς το με μεγάλο περιθώριο και εξελιγμένους μηχανισμούς μεριδίου QoS και περιορισμού.
  • Οι κάτοχοι υπηρεσιών μπορούν να μετακινήσουν φόρτους εργασίας μεταξύ κελιών, όπως απαιτείται. Ακολουθούν μερικά παραδείγματα σεναρίων:
    • Για την αποφυγή του ζητήματος "θορυβώδεις γείτονες" πολλαπλών εκμισθωτών, μετακινώντας έναν βαρύ φόρτο εργασίας ώστε να μην επηρεάζονται οι άλλοι χρήστες ενός κελιού.
    • Για την επαναφορά από υπερφόρτωση ή μείωση τάσης, η οποία προκαλείται ενδεχομένως από μια διανεμημένη επίθεση άρνησης υπηρεσίας. Διαθέτουμε μηχανισμούς μεριδίου και περιορισμού για προστασία από τέτοιου είδους επιθέσεις, ωστόσο, κάποιες φορές παρουσιάζονται σπάνιες περιπτώσεις στις οποίες μια συγκεκριμένη περίπτωση χρήσης (API, μοτίβο πρόσβασης) είναι πιο επίπονη για την υπηρεσία από ό,τι αντιλαμβάνεται το σύστημα μεριδίου ή περιορισμού. Τα κελιά παρέχουν έναν μηχανισμό για βραχυπρόθεσμο μετριασμό.
    • Για τον διαχωρισμό των κρίσιμων φόρτων εργασίας σε διαφορετικά κελιά ώστε να μειωθεί σημαντικά η πιθανότητα συσχετισμένης αποτυχίας. Για παράδειγμα, για την εσωτερική κοινόχρηστη υπηρεσία Workflow για τα επίπεδα ελέγχου, τα "κύρια κρίσιμα" επίπεδα ελέγχου (για παράδειγμα, οι υπηρεσίες Platform, Compute, Networking και Block Volumes) αντιστοιχίζονται σε διαφορετικά κελιά και, επομένως, έχουν σημαντικά λιγότερη συσχέτιση αποτυχίας από ό,τι θα είχαν αν δεν χρησιμοποιούνταν κελιά ή δεν είχαν αντιστοιχιστεί στο ίδιο κελί.
      Σημείωση: Αυτή η χρήση κελιών μειώνει την ανάγκη των πελατών να λάβουν υπόψη τους τις εξαρτήσεις των υπηρεσιών ώστε να δημιουργήσουν ανθεκτικές εφαρμογές. Το γράφημα εξαρτήσεων εξακολουθεί να είναι μια καλή πρακτική (παρακάτω θα βρείτε περισσότερες πληροφορίες για αυτό), αλλά είναι λιγότερο απαραίτητο όταν ένας μηχανικός κατάργησης συσχέτισης είναι ήδη ενεργός.

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

Συνοπτικά, τα κελιά υπηρεσιών και οι τομείς σφαλμάτων αλληλοσυμπληρώνονται με τους ακόλουθους τρόπους:

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

Συνδυάζουμε τις ιδιότητες των τομέων σφαλμάτων και των κελιών υπηρεσιών σε μια ενοποιημένη στρατηγική κατά τη διάρκεια των αναπτύξεων και επιδιορθώσεων.

Διαδικασίες μηχανικής υπηρεσιών

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

  • Αναπτύσσουμε τις υπηρεσίες σταδιακά με προσεκτική επικύρωση μεταξύ των βημάτων και αντανακλαστική επαναφορά σε περίπτωση που συμβεί κάτι μη αναμενόμενο. Πιο συγκεκριμένα, η διαδικασία έχει ως εξής:
    • Σε κάθε τομέα διαθεσιμότητας, πραγματοποιούμε ανάπτυξη σε ένα κελί υπηρεσίας κάθε φορά. Για κάθε κελί, πραγματοποιούμε ανάπτυξη σε έναν τομέα σφαλμάτων κάθε φορά, μέχρι να ολοκληρωθούν όλοι οι τομείς σφαλμάτων για αυτό το κελί. Στη συνέχεια, προχωράμε στο επόμενο κελί σε αυτόν τον τομέα διαθεσιμότητας.
    • Μετά από κάθε βήμα της ανάπτυξης (ύστερα από κάθε τομέα σφαλμάτων και κελί), επαληθεύουμε ότι η αλλαγή λειτουργεί όπως προβλέπεται, δηλαδή, ότι δεν έχουμε υποβαθμίσει την απόδοση ή δημιουργήσει εσωτερικά ή εξωτερικά σφάλματα. Αν παρατηρήσουμε οποιοδήποτε πρόβλημα ή κάτι μη αναμενόμενο, αναιρούμε άμεσα την αλλαγή. Δίνουμε μεγάλη έμφαση στην προετοιμασία και τη δοκιμή, συμπεριλαμβανομένης της αυτοματοποιημένης δοκιμής των διαδικασιών επαναφοράς και των αλλαγών που επηρεάζουν τη μόνιμη κατάσταση ή τα σχήματα.
    • Με αυτόν τον τρόπο, αναπτύσσουμε την αλλαγή σε έναν τομέα διαθεσιμότητας κάθε φορά σε κάθε περιοχή. Πραγματοποιούμε ανάπτυξη σε όλες τις περιοχές μιας ευρύτερης περιοχής έτσι ώστε να μην τροποποιούμε ταυτόχρονα ζεύγη περιοχών που ένας πελάτης μπορεί να χρησιμοποιεί ως κύριες τοποθεσίες και τοποθεσίες ανάκτησης μετά από καταστροφή.
  • Επαληθεύουμε τακτικά τη σωστή λειτουργία των μηχανισμών χειρισμού σφαλμάτων και άλλων λειτουργιών μετριασμού και βεβαιωνόμαστε ότι το πρόβλημα δεν κλιμακώνεται. Χωρίς τέτοιες δοκιμές, είναι σύνηθες για αυτούς τους μηχανισμούς χειρισμού σφαλμάτων (όπως επαναλήψεις, αλγόριθμοι ανάκτησης μετά από διακοπή λειτουργίας και αλγόριθμοι επαναδιαμόρφωσης κατάστασης υπολογιστών) να έχουν σφάλματα, να κοστίζουν πολύ ή να αλληλεπιδρούν με απρόσμενο τρόπο και να προκαλούν διανεμημένο λυγισμό μνήμης ή άλλα σοβαρά προβλήματα απόδοσης.
  • Επαληθεύουμε τη δυνατότητά μας να πραγματοποιούμε επαναφορά γρήγορα και με ασφάλεια στο τελευταίο λογισμικό και τη διαμόρφωση που λειτουργούσαν κανονικά, συμπεριλαμβανομένης της μόνιμης κατάστασης και σχήματος, όπως περιγράφεται παραπάνω.
 
 

Στις περιοχές της Oracle που περιέχουν πολλούς τομείς διαθεσιμότητας, διανέμονται όλες οι κρίσιμες υπηρεσίες στους τομείς διαθεσιμότητας;

Ναι. Σε κάθε περιοχή, όλοι οι τομείς διαθεσιμότητας προσφέρουν το ίδιο σύνολο υπηρεσιών.

 
 

Πώς αποφεύγουν η Oracle και οι πελάτες της να έχουν μια κρίσιμη υπηρεσία που εξαρτάται από ένα μοναδικό λογικό κέντρο δεδομένων;

Στις περιοχές με έναν τομέα διαθεσιμότητας, οι πελάτες μπορούν να χρησιμοποιήσουν τομείς σφαλμάτων (λογικές ομάδες με μη συσχετισμένες λειτουργείες αποτυχίας μεταξύ των ομάδων) ώστε να έχουν τις περισσότερες ιδιότητες των ξεχωριστών "λογικών κέντρων δεδομένων". Οι πελάτες μπορούν επίσης να χρησιμοποιήσουν πολλές περιοχές για ανάκτηση μετά από καταστροφή.

Στις περιοχές με πολλούς τομείς διαθεσιμότητας, οι πελάτες μπορούν να χρησιμοποιήσουν τομείς σφαλμάτων με τον ίδιο τρόπο. Επίσης, οι πελάτες μπορούν να χρησιμοποιήσουν έναν συνδυασμό τοπικών υπηρεσιών τομέων διαθεσιμότητας, λειτουργίες ανακατεύθυνσης μεταξύ τομέων διαθεσιμότητας (όπως DBaaS με Data Guard) και υπηρεσίες περιοχής (Object Storage, Streaming) για να επιτύχουν υψηλό HA σε "λογικά κέντρα δεδομένων" υψηλότερου επιπέδου (τομείς διαθεσιμότητας). Τέλος, οι πελάτες μπορούν επίσης να χρησιμοποιήσουν πολλές περιοχές για ανάκτηση μετά από καταστροφή.

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

 
 

Πώς η Oracle εκτελεί εργασίες συντήρησης διατηρώντας σε λειτουργία τις κρίσιμες υπηρεσίες για όλους τους πελάτες;

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

 
 

Οι υπηρεσίες πλατφόρμας χωρίς server αναπτύσσονται σε πολλά λογικά κέντρα δεδομένων για υψηλότερη διαθεσιμότητα;

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

 
 

Αν η ανθεκτικότητα δεν είναι η προεπιλεγμένη διαμόρφωση, προσφέρεται στους πελάτες η επιλογή για ανάπτυξη πολλών λογικών κέντρων δεδομένων (για παράδειγμα, μια διαμόρφωση πολλών τομέων διαθεσιμότητας ή μια διαμόρφωση μεταξύ περιοχών);

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

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

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

 
 

Πώς βοηθάει η Oracle τους πελάτες να αποφύγουν τη συσχετισμένη αποτυχία εφαρμογών που δημιουργείται από εσωτερικές εξαρτήσεις μεταξύ των διάφορων υπηρεσιών υποδομής και πλατφόρμας;

Αυτή είναι μια περίπλοκη ερώτηση και για να την απαντήσουμε πρέπει να τη θέσουμε με δύο διαφορετικούς τρόπους:

  • Αν ένας πελάτης θέλει να χρησιμοποιήσει δύο υπηρεσίες της Oracle (υπηρεσία A και υπηρεσία B) και θέλει να δημιουργήσει μια εφαρμογή που είναι ανθεκτική σε περίπτωση που κάποια από αυτές τις υπηρεσίες αποτύχει, θα πρέπει ο πελάτης να γνωρίζει αν η υπηρεσία A εξαρτάται εσωτερικά από την υπηρεσία B; Οι εσωτερικές εξαρτήσεις οδηγούν σε συσχετισμένη αποτυχία σε σημαντικό βαθμό; Αν ναι, ο πελάτης ίσως πρέπει να είναι ενήμερος για τέτοιες εσωτερικές εξαρτήσεις ώστε να αποφασίσει με ποιους άλλους τρόπους θα χρησιμοποιήσει τις υπηρεσίες A και B —ή αν για αυτές τις επιπλέον περιπτώσεις πρέπει να χρησιμοποιήσει μια υπηρεσία Γ που δεν σχετίζεται— κατά τη δημιουργία των μηχανισμών ανθεκτικότητας σε επίπεδο εφαρμογής.
  • Πώς μπορεί ο πελάτης να προστατευτεί από τυχόν συσχετισμένες αποτυχίες στις υπηρεσίες της Oracle;

Η απάντηση δίνεται σε δύο μέρη.

Αρχές αρχιτεκτονικής

Χρησιμοποιούμε αρχές αρχιτεκτονικής που μειώνουν σημαντικά τις πιθανότητες συσχετισμένης αποτυχίας στις εξαρτώμενες υπηρεσίες. Σε ορισμένες περιπτώσεις, αυτή η τεχνική μειώνει τη πιθανότητα μιας συσχετισμένης αποτυχίας σε βαθμό που μπορεί να παραβλεφθεί όσον αφορά την ικανοποίηση μιας σύμβασης παροχής υπηρεσιών (SLA) διαθεσιμότητας.

Συγκεκριμένα, χρησιμοποιούμε κελιά υπηρεσιών όπως περιγράφεται παραπάνω σε αυτό το έγγραφο. Τα κελιά βοηθούν με αυτό το πρόβλημα επειδή αν μια εσωτερική υπηρεσία A επηρεάζεται από ένα πρόβλημα σε μία από τις εξαρτήσεις της, την υπηρεσία Β, τότε το πρόβλημα στην υπηρεσία B πιθανώς περιορίζεται σε ένα μόνο κελί. Άλλες υπηρεσίες υψηλότερου επιπέδου —όπως και οι εφαρμογές του πελάτη— που χρησιμοποιούν την υπηρεσία B πιθανώς χρησιμοποιούν άλλα κελιά που δεν επηρεάζονται. Αυτή είναι μια έκφραση πιθανολογικής φύσης που ποικίλει ανάλογα με τον αριθμό των κελιών, η οποία είναι μια κρυφή εσωτερική παράμετρος που αλλάζει (αυξάνεται) και, επομένως, δεν μπορεί να δοθεί εγγύηση ή ποσοτικός προσδιορισμός πέρα από τις μεμονωμένες συμβάσεις παροχής υπηρεσιών για τις υπηρεσίες A και B. Ωστόσο, στην πράξη, αυτό μπορεί να καταργήσει σημαντικά τη συσχέτιση των αποτυχιών μεταξύ των υπηρεσιών.

Πολλές από τις κοινόχρηστες εσωτερικές υπηρεσίες σας —για παράδειγμα, οι υπηρεσίες Workflow και Metadata για τα επίπεδα ελέγχου και η υπηρεσία Streaming/Messaging— χρησιμοποιούν κελιά υπηρεσιών ώστε να καταργήσουν τη συσχέτιση των διακοπών λειτουργίας για τις ανοδικές υπηρεσίες που τα χρησιμοποιούν.

Εξαρτήσεις

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

Για τα επίπεδα ελέγχου, οι συνήθεις εξαρτήσεις έχουν ως εξής:

  1. Το επίπεδο δεδομένων Identity/Platform για έλεγχο ταυτότητας και εξουσιοδότηση
  2. Η υπηρεσία παρακολούθησης ελέγχου
  3. Εσωτερικές υπηρεσίες που παρέχουν, για παράδειγμα, ροή εργασίας, χώρο αποθήκευσης μεταδεδομένων και καταγραφή
  4. Εργαλεία εξισορρόπησης φόρτου διάφορων τύπων

Ορισμένα επίπεδα ελέγχου προφανώς έχουν εξαρτήσεις με συγκεκριμένες υπηρεσίες. Για παράδειγμα, κατά την εκκίνηση ενός σκελετικού στιγμιότυπου ή ενός στιγμιότυπου εικονικού υπολογιστή, το επίπεδο ελέγχου Compute εξαρτάται από:

  • Την υπηρεσία Object Storage (για ανάκτηση του καθορισμένου ειδώλου λειτουργικού συστήματος)
  • Το επίπεδο ελέγχου Block Volumes (για παροχή και προσάρτηση του τόμου εκκίνησης)
  • Το επίπεδο ελέγχου Networking (για παροχή και προσάρτηση VNIC)

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

  • Το επίπεδο δεδομένων Networking είναι αυτόνομο.
  • Το επίπεδο δεδομένων Block Volumes είναι αυτόνομο.
  • Τα σκελετικά στιγμιότυπα Compute και εικονικού υπολογιστή εξαρτώνται από το επίπεδο δεδομένων Block Volumes (για τόμους εκκίνησης) και το επίπεδο δεδομένων Networking.
  • Το επίπεδο δεδομένων Object Storage εξαρτάται από το επίπεδο δεδομένων Identity/Platform για έλεγχο ταυτότητας και εξουσιοδότηση (εξαιτίας απαιτήσεων του κλάδου). Το επίπεδο δεδομένων Object Storage δεν εξαρτάται από τις υπηρεσίες Block Volumes ή File Storage.
  • Όλες οι υπηρεσίες που υποστηρίζουν τη δημιουργία και επαναφορά εφεδρικών αντιγράφων εξαρτώνται από το επίπεδο δεδομένων Object Storage για αυτήν τη λειτουργία.

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

  • Το Database multi-node RAC εξαρτάται από τα επίπεδα δεδομένων Networking και Block Volumes.
  • Το Container Engine for Kubernetes προφανώς εξαρτάται από το Kubernetes και τις μεταβατικές εξαρτήσεις του (για παράδειγμα, etcd) καθώς και το επίπεδο δεδομένων Networking.
  • Όλη η υποστήριξη για τις λειτουργίας δημιουργίας και επαναφοράς εφεδρικών αντιγράφων εξαρτώνται από το επίπεδο δεδομένων Object Store.

1Ένα δημόσιο ερευνητικό πρόγραμμα από τα πανεπιστήμια Stanford και Berkeley υπό τη διεύθυνση των Armando Fox και Dave Patterson

 
×
Καλέστε μας τώρα
1-800-633-0738 (Ηνωμένες Πολιτείες)

Επικοινωνία
×
Καλέστε μας τώρα
1-800-633-0738 (Ηνωμένες Πολιτείες)


Φόρουμ συζητήσεων για το Oracle Cloud