HSM: Η αρχική μηχανή βαθμολόγησης πίσω από τα mainframes, το cloud και το S3

Εάν νομίζετε ότι η «συσσώρευση» ξεκίνησε με τις κλάσεις αποθήκευσης SSD και cloud... συγχαρητήρια: έχετε προωθηθεί με επιτυχία. Έχει κάνει την ίδια βασική δουλειά εδώ και δεκαετίες: Hierarchical Storage Management (HSM) Κρατήστε «καυτά» δεδομένα σε γρήγορα, ακριβά μέσα ενημέρωσης ... πιέστε «κρύα» δεδομένα σε πιο αργά, φθηνότερα μέσα ενημέρωσης ... και κάνετε τον χρήστη να ξεχάσει ως επί το πλείστον ότι υπάρχεις - μέχρι να τους υπενθυμίσει η καθυστέρηση υπενθύμισης ότι το κάνεις. Κρατήστε «καυτά» δεδομένα σε γρήγορα, ακριβά μέσα ενημέρωσης ... πιέστε «κρύα» δεδομένα σε πιο αργά, φθηνότερα μέσα ενημέρωσης ... και κάνετε τον χρήστη να ξεχάσει ως επί το πλείστον ότι υπάρχεις - μέχρι να τους υπενθυμίσει η καθυστέρηση υπενθύμισης ότι το κάνεις. Αυτό που άλλαξε τα τελευταία 50 χρόνια δεν είναι Είναι η Η Η , και οι **way πωλητές προσπαθούν να μετονομάσουν το ίδιο πράγμα έτσι ώστε η προμήθεια να αισθάνεται σαν να αγοράζει "καινοτομία". 😄 Ιδέα media interfaces scale What is HSM, really? Τι είναι πραγματικά το HSM; Η ιεραρχική διαχείριση αποθήκευσης (HSM) είναι το παλαιότερο μαγικό κόλπο του κόσμου αποθήκευσης: Οι χρήστες βλέπουν τα ίδια αρχεία.Οι διαχειριστές βλέπουν λιγότερα εισιτήρια "πλήρους δίσκου".Όλοι προσποιούνται ότι η καθυστέρηση υπενθύμισης δεν είναι πραγματική μέχρι κάποιος να κάνει διπλό κλικ σε ένα αρχείο 400 GB που έχει ζήσει την καλύτερη ζωή του σε βαθιά αρχειοθέτηση. make expensive storage look bigger by quietly moving data to cheaper tiers—without breaking the namespace Στον πυρήνα της, Με κάποιο είδος Ιστορικά, η ιεραρχία ήταν «γρήγορος δίσκος → βραδύτερος δίσκος → ταινία / οπτική».Στις σύγχρονες στοίβες είναι συχνά «καυτό → δροσερό → κρύο → αρχείο», μερικές φορές που κυμαίνονται από on-prem, αντικείμενο και cloud. HSM is policy-driven data placement across a storage hierarchy recall path The five moving parts of classic HSM (and why each matters) 1) A primary tier: where “now” lives Αυτή είναι η αποθήκευση που πρέπει να συμπεριφέρεται σαν αποθήκευση: γρήγορο δίσκο, SSD, NAS υψηλής απόδοσης, scratch ή ένα παράλληλο σύστημα αρχείων Χαμηλή καθυστέρηση και υψηλή απόδοση Βελτιστοποιημένα για ενεργές ροές εργασίας Αυτό το ζώο είναι όπου θέλετε δεκαετίες «μόνο σε περίπτωση» να συσσωρευτούν. Όχι 2) Secondary tiers: where “later” lives Το HSM είναι ενδιαφέρον μόνο αν υπάρχει ένα φθηνότερο μέρος για να τοποθετήσετε κρύα δεδομένα: ικανότητα δίσκου Αποθήκευση αντικειμένων Ετικέτες Βιβλιοθήκες οπτικά ή άλλα μέσα μακράς διατήρησης Αυτά τα επίπεδα συναλλαγών απόδοση για την οικονομία (κόστος / GB, ισχύ, πυκνότητα, μακροζωία). . what belongs where and when 3) A policy engine: the brains (and the source of most arguments) Οι πολιτικοί αποφασίζουν και Τα κλασικά εισερχόμενα μοιάζουν: Τι κινείται ΓΙΑΤΙ Ηλικία / Πρόσφατο (mtime, atime, «τελευταία αναφορά») μέγεθος (τα μεγάλα αρχεία είναι κύριοι υποψήφιοι μετανάστευσης) path/project (όλα κάτω από το /project/foo/ ακολουθούν τους κανόνες foo) ιδιοκτησία (πολιτικές βάσει χρήστη/ομάδας) θερμοκρασία (θερμή / ζεστή / κρύα ευριστική) Οι σύγχρονες μηχανές πολιτικής προσθέτουν: Ετικέτες / μεταδεδομένα (συστήματα αντικειμένων) Σήματα ροής εργασίας (εργασία ολοκληρωμένη, έργο κλειστό) κράτος συμμόρφωσης (κράτηση, νομική κατοχή) σήματα κόστους (χρεώσεις ανάκτησης, έκθεση εκροής) Μια καλή μηχανή πολιτικής δεν μεταφέρει μόνο δεδομένα – σας εμποδίζει να μεταφέρετε τα δεδομένα. δεδομένων και να μάθουν γι 'αυτό στην παραγωγή. Λάθος 4) A recall mechanism: how the illusion stays intact Αυτό είναι το στοιχείο «μην σπάσετε τους χρήστες». Στο κεντρικό αρχείο HSM, η ανάκληση συχνά ενεργοποιείται από: αρχεία stub / κάτοχοι θέσης που διατηρούν το όνομα, το μέγεθος, τις χρονικές πινακίδες, τα δικαιώματα κ.λπ. Το σύστημα αρχείων δεσμεύεται/εκδηλώνεται έτσι ώστε το "open()" να ενεργοποιεί αυτόματα το stage-back throttling/queuing έτσι ώστε μία σάρωση δεν θυμάται τον πλανήτη Στο αντικειμενοκεντρικό HSM / κύκλο ζωής, η ανάκληση μπορεί να μοιάζει με: Επαναφορά / επαναφορά θέσεων εργασίας Αντίγραφα σε ζεστό δοχείο / χώρο εργασίας Προσωρινή πρόσβαση Windows ρητά βήματα ροής εργασίας αντί για «διαφανή ανάκληση» Είτε έτσι είτε αλλιώς, η ανάκληση είναι όπου το HSM γίνεται πραγματικότητα. Είναι το σκληρό μέρος. Getting it back safely, predictably, and at scale 5) A migration engine: the muscle and the traffic cops Αυτό είναι που στην πραγματικότητα μετακινεί τα bytes και εμποδίζει το σύστημα να λιώσει: μετακινητές (διαδικασίες μεταφοράς δεδομένων / οικοδεσπότες) ΠΡΟΤΕΡΑΙΟΤΗΤΕΣ ΚΑΙ ΠΡΟΤΕΡΑΙΟΤΗΤΕΣ Παράλληλες ροές Τηλεφωνική γραμμή throttle διαχειριστές μέσων ενημέρωσης (ειδικά για την ταινία / ρομποτική) Λογική αναζήτησης, έλεγχος και παρακολούθηση κατάστασης Αν έχετε δει ποτέ μια καταιγίδα ανάκλησης, γνωρίζετε ήδη: η μηχανή μετανάστευσης δεν είναι μόνο ένας αντιγράφος. What HSM is (because people keep using the word wrong) not Όχι HSM is not backup Πρόκειται για την ανάκτηση μετά από απώλεια / διαφθορά. Το HSM είναι για τη βελτιστοποίηση του χώρου και του κόστους μέσω της μετεγκατάστασης. Backup Ορισμένα συστήματα τα συνδυάζουν, αλλά η πρόθεση είναι διαφορετική: Η HSM μετακινεί τα δεδομένα από τον πρωτογενή σε ελεύθερο χώρο (και αναμένει την ανάκληση για εργασία) Το αντίγραφο ασφαλείας δημιουργεί πρόσθετα αντίγραφα για ανάκτηση (και δεν υποθέτει ότι το πρωτεύον αντίγραφο εξαφανίζεται) Εάν το "HSM" διαγράφει πρωτογενή δεδομένα, αλλά δεν έχετε ανεξάρτητο ιστορικό ανάκτησης, αυτό δεν είναι HSM - αυτό είναι . Βάσει της πίστης HSM is not caching αντιγράφει τα θερμά μπλοκ/δεδομένα πιο κοντά στον υπολογισμό, αφήνοντας το αυθεντικό αντίγραφο στη θέση του. Τυπικά Μια διαφορετική κοινωνία βασισμένη στην πολιτική. Caching HSM relocates entire files/objects Το caching λέει: «Κρατήστε ένα γρήγορο αντίγραφο κοντά». Η HSM λέει: «Αυτό δεν ανήκει πλέον στην ακριβή αποθήκευση - μετακινήστε το». Μπορούν (και συχνά πρέπει) να συνυπάρχουν, αλλά επιλύουν διαφορετικά προβλήματα. The simplest way to think about HSM Το HSM είναι ένα governed lifecycle for data placement: Αποφασίστε τι είναι ζεστό vs κρύο Μετακίνηση κρύων δεδομένων σε φθηνότερα επίπεδα Διατηρήστε τη σημασιολογία της πρόσβασης όσο πρακτική Ο έλεγχος επαναλαμβάνεται έτσι ώστε να είναι προβλέψιμη παρακολούθηση της κατάστασης, ώστε να μπορείτε να αποδείξετε πού βρίσκονται τα δεδομένα και γιατί Το παλιό HSM το έκανε αυτό με ράβδους και ρομπότ ταινιών. Η σύγχρονη HSM το κάνει με κανόνες κύκλου ζωής, μεταδεδομένα αντικειμένων και ροές εργασίας αποκατάστασης. Η ίδια δουλειά. νέα διεπαφή. οι ίδιες επιχειρησιακές παγίδες booby. HSM vs ILM: same family, different job titles HSM vs ILM: Η ίδια οικογένεια, διαφορετικοί τίτλοι εργασίας Οι άνθρωποι ανακατεύονται και επειδή οι πωλητές πέρασαν δύο δεκαετίες χρησιμοποιώντας και τους δύο όρους ως ανταλλακτικά μάρκετινγκ. Hierarchical Storage Management (HSM) Information Lifecycle Management (ILM) Σκεφτείτε το έτσι: Το HSM είναι ένας μηχανισμός που μεταφέρει δεδομένα μεταξύ των επιπέδων. Το ILM αποφασίζει τι πρέπει να κάνει ο οργανισμός με τα δεδομένα με την πάροδο του χρόνου – και αποδεικνύει ότι το έκανε. Το μασάζ είναι χρήσιμο εδώ: Αυτό ευθυγραμμίζει το Πληροφορίες με , και σε όλο τον κύκλο ζωής των πληροφοριών - όχι ένα μόνο κουτί που αγοράζετε και συνδέετε. SNIA’s ILM is an ongoing strategy αξία policies processes supporting infrastructure The lifecycle view: ILM starts before storage gets involved Το ILM ξεκινά τη στιγμή που δημιουργούνται ή αποκτώνται δεδομένα και συνεχίζεται μέχρι την τελική διάθεση. Δημιουργία / εισαγωγή (πώς εισέρχεται στο org, ποια μεταδεδομένα / ετικέτες υπάρχουν) Ενεργή χρήση (ποιος μπορεί να έχει πρόσβαση σε αυτό, απαιτήσεις απόδοσης) Συνεργασία / Κοινή χρήση (διανομή, αντιγραφή, αντίγραφα, εκδόσεις) Προστασία (αποθήκευση, στιγμιότυπα, αναπαραγωγή, ακεραιότητα / σταθερότητα) Μακροπρόθεσμη διατήρηση (αρχεία, αρχεία, ερευνητικές συλλογές) Διακυβέρνηση (νομικές διατάξεις, κανόνες απορρήτου, έλεγχοι πρόσβασης) Διαγραφή (διαγραφή, καταστροφή, μεταβίβαση, ανακατανομή) Το HSM εμφανίζεται συνήθως στη μέση αυτής της ιστορίας ως το στρώμα εκτέλεσης "μετακινήστε το σε φθηνότερη αποθήκευση" - όχι ως αρχή πολιτικής που αποφασίζει τι διατηρείται, για πόσο και κάτω από ποιους νομικούς περιορισμούς. Practical translation (the one you actually use in architecture meetings) HSM = the machinery (execution layer) Το HSM είναι το σύνολο των τεχνικών δυνατοτήτων που κάνουν το tiering πραγματικό: Επίπεδο / τοποθέτηση σε κατηγορίες δίσκου, αντικειμένου, ταινίας, σύννεφο Κανόνες μετανάστευσης και εκκαθάρισης για δωρεάν πρωτογενή αποθήκευση Ανακαλέστε / επαναφέρετε ροές εργασίας (ανακαλέστε τις θέσεις εργασίας, επαναφέρετε την υγρασία, επαναφέρετε τις θέσεις εργασίας) Μετακινήσεις και ουρές (διανομή, τράβηγμα, προτεραιότητα) Διαχείριση μέσων ενημέρωσης (βιβλιοθήκες ταινιών, κατάλογοι όγκου, έλεγχος ρομποτικής) Παρακολούθηση κατάστασης (κατοικεί / εκτός σύνδεσης, αποκατάσταση σε εξέλιξη, προσκολλημένη κ.λπ.) Η HSM απαντά: «Πού ζουν αυτά τα δεδομένα σήμερα, και πώς τα μεταφέρουμε;» ILM = the governance layer (intent + accountability) Το ILM είναι το πλαίσιο που συνδέει την επεξεργασία δεδομένων με τις επιχειρηματικές και νομικές απαιτήσεις: Χρονοδιαγράμματα διατήρησης (κρατήστε για 7 χρόνια, κρατήστε για πάντα, κρατήστε μέχρι να κλείσει η υπόθεση) Συμμόρφωση και δυνατότητα ελέγχου (απόδειξη ότι δεν έχει τροποποιηθεί, απόδειξη διαγραφής) Νομική κατοχή (παγώστε τη διάθεση και μερικές φορές παγώστε την κίνηση) Ταξινόμηση (δημόσια, εσωτερική, περιορισμένη, ευαίσθητη) Διαχείριση κινδύνου και κόστους (ποια κατηγορία αποθήκευσης είναι αποδεκτή, ανοχές ανάκτησης) Διαχείριση (αμυντική διαγραφή, μεταβίβαση ή διατήρηση) Πολιτική ιδιοκτησίας (ποιος εγκρίνει, ποιος αλλάζει, ποιος υπογράφει) Ελεγκτικότητα Νομική holds Ταξινόμηση διάταξη Πολιτική ownership ILM answers: “What must happen to this data over its life, and can we prove it?” Where people go wrong: buying “ILM” as if it’s a product Πολλοί προμηθευτές πωλούν το "ILM" ως πακέτο χαρακτηριστικών.Το πρόβλημα είναι ότι το ILM δεν είναι ένα χαρακτηριστικό, είναι ένα σύστημα διασταύρωσης: organizational policy (records management, legal, security) επιχειρησιακές διαδικασίες (εγκρίσεις, έλεγχοι, εξαιρέσεις, διαχείριση συμβάντων) εργαλειοποίηση (μεταδεδομένα / σήμανση, ανάλυση, κινητήρες κίνησης, επιβολή της διατήρησης) You can buy components that support ILM, but the “ILM” part is the and -και κανένα πλοίο πωλητή που έχει προετοιμαστεί για να ταιριάζει με τις ρυθμιστικές σας υποχρεώσεις και την εσωτερική πολιτική. (Αν ισχυρίζονται ότι το κάνουν, σας πωλούν αισιοδοξία.) coordination accountability How they fit together in a modern stack Ένας χρήσιμος τρόπος για να το περιγράψετε στο άρθρο σας: Η ILM ορίζει την πρόθεση: διατήρηση, κανόνες πρόσβασης, αποδεκτή καθυστέρηση, περιορισμούς κόστους, υποχρεώσεις συμμόρφωσης. Η HSM εκτελεί την τοποθέτηση: μετανάστευση, μεταβάσεις επιπέδων, ροές εργασίας αποκατάστασης και μηχανισμούς επιβολής. ** Για παράδειγμα : **ILM says: “This collection must be retained for 25 years, immutable, with restores allowed but tracked, and retrieval should be under 24 hours.” HSM υλοποιεί: «Μετά από 90 ημέρες, μετάβαση στο επίπεδο κρύο / αρχειοθέτησης. ενεργοποιήστε την αποκατάσταση της ροής εργασίας. περιορίστε ποιος μπορεί να rehydrate. log επαναφέρει. επιβάλει την αμετάβλητη». Το ILM είναι το «γιατί» και οι «κανόνες του δρόμου».Το HSM είναι το «πώς» - η μηχανή που μετακινεί τα δεδομένα σε διάφορα επίπεδα με τρόπο που ταιριάζει με αυτούς τους κανόνες, ειδικά σε περιβάλλοντα κεντρικά σε αρχεία και υβριδικά. Ένα γρήγορο χρονοδιάγραμμα: mainframe → open systems → HPC → clustered file → object/cloud Mainframe roots (late 1970s through the 1980s): policy before it was cool Το Mainframe HSM δεν γεννήθηκε ως ένα «καλό-to-have». εμφανίστηκε επειδή η συσκευή αποθήκευσης άμεσης πρόσβασης (DASD) ήταν δαπανηρή, η ανάπτυξη των δεδομένων ήταν αμείλικτη και κανείς δεν ήταν εθελοντής για να παρακολουθεί χειροκίνητα τα δεδομένα σε 2 π.μ. από τον Ιεραρχικό Διαχειριστή Αποθήκευσης (HSM) της IBM (αργότερα) Αργότερα ) εισήχθη το 1978 ειδικά για την αυτοματοποίηση της διαχείρισης αποθήκευσης για σύνολα δεδομένων χρησιμοποιώντας απλά, επαναλαμβανόμενα κριτήρια. DFHSM DFSMShsm Τι τόνισε το mainframe HSM Automated space management: periodic, policy-driven cleanup and migration so primary pools didn’t stay “full forever.” Hierarchical “levels” of storage: data sets moved from primary volumes to cheaper tiers (including Migration Level 2 (ML2), typically on tape and usually not mounted/online). Operational stability: predictable policy cycles (batch windows), consistent reporting, and a control plane storage admins could actually run. **Άλλα προϊόντα τύπου HSM στην ίδια εποχή \ Η IBM δεν ήταν η μόνη που κυνηγούσε το ίδιο αποτέλεσμα. (now Broadcom), which combined archive, space release, and movement across the storage hierarchy—meaning it attacked the same problem from a “data management suite” angle rather than IBM’s DFSMS-integrated path. CA Disk Backup and Restore Key point: the mainframe world treated policy-driven automation as normal because it had to. You can’t staff your way out of exponential growth—especially when the platform is designed around repeatable operations, not heroics. Open systems in the 1980s: UNIX grows up, libraries get robotic (and HSM becomes a “stack”) Καθώς το UNIX εξαπλώθηκε σε εργαστήρια, καταστήματα μηχανικής και πρώιμα επιχειρηματικά περιβάλλοντα, το HSM σταμάτησε να είναι ένα μοναδικό χαρακτηριστικό πλατφόρμας και μετατράπηκε σε ένα οικοσύστημα προμηθευτών: υπηρεσίες αρχείων στην κορυφή, αυτοματοποίηση των μέσων ενημέρωσης στο κάτω μέρος και μια μηχανή πολιτικής που προσπαθεί να αποτρέψει τον δίσκο από το να αντιμετωπίζεται ως ένας άπειρος πόρος (spoiler: δεν ήταν). Τι ανοιχτά συστήματα HSM τόνισε σε αυτή την εποχή Robotic tape libraries and optical jukeboxes become real infrastructure, not science-fair props. Media managers and volume services start to matter , because someone has to track cartridges, drives, mounts, and “where the heck did that volume go?” as much as the file system Εδώ είναι όπου το EMASS εμφανίζεται ως ένα πραγματικό "HSM stack" Το EMASS FileServ ήταν το στρώμα διαχείρισης HSM / file-space - το μέρος που χειρίζεται τη συμπεριφορά σε επίπεδο αρχείου και τη λογική "κάντε το να φαίνεται ότι εξακολουθεί να υπάρχει". Το EMASS VolServ ήταν το στρώμα της Φυσικής Βιβλιοθήκης Όγκου (PVL) – κεντρική διαχείριση μέσων ενημέρωσης, έλεγχος ρομποτικής, αυτοματοποίηση τοποθέτησης / αποσυναρμολόγησης, υποστήριξη πολλαπλών πελατών και οι λεπτομέρειες της εκτέλεσης μιας βιβλιοθήκης σε κλίμακα. η NASA / τεχνική βιβλιογραφία περιγράφει το VolServ ειδικά με όρους PVL (κεντρική διαχείριση μέσων ενημέρωσης και αυτοματοποιημένη τοποθέτηση / αποσυναρμολόγηση) και περιγράφει το EMASS ως μια ιεραρχική οικογένεια αποθήκευσης μάζας που παρέχει διαχείριση χώρου αποθήκευσης / αρχείου. In other words: FileServ is the “HSM brain for files,” VolServ is the “robot wrangler for media.” Together they’re a clean example of how open-systems HSM became modular. Και αυτή η εποχή περιλαμβάνει επίσης προϊόντα HSM-adjacent "αρχείο ως σύστημα αρχείων" Η ADIC AMASS περιέγραψε τη μακροπρόθεσμη αποθήκευση ως κάτι που οι χρήστες θα μπορούσαν να έχουν πρόσβαση με τις ίδιες εφαρμογές που χρησιμοποιούσαν για δίσκο - παρουσιάζοντας αρχείο πίσω από ένα σύστημα αρχείων που μοιάζει με αφαίρεση σε ταινίες / οπτικές βιβλιοθήκες. Key point: In the 1980s open-systems world, HSM becomes a layered architecture: file services + movers + volume/media management + robotics. That blueprint is basically the ancestor of today’s “lifecycle + object + cloud” designs—just with more SCSI and fewer REST APIs. The 1990s supercomputer/HPC era: HSM becomes “mass storage” (and gets serious) Όταν οι χρήστες σας εκτελούν εργασίες πολλαπλών κόμβων που μπορούν να μασήσουν μέσα από terabytes όπως το ποπ κορν, το HSM δεν είναι μόνο για την απελευθέρωση χώρου - είναι για την τροφοδοσία υπολογιστών χωρίς να μετατρέπουν τον προϋπολογισμό αποθήκευσης σε μια σκηνή εγκλήματος. Η αρχιτεκτονική του περιλαμβάνει ρητά μια λειτουργία Migration/Purge που παρέχει ιεραρχική διαχείριση αποθήκευσης μέσω της μετεγκατάστασης και της προσωρινής αποθήκευσης μεταξύ δίσκου και ταινίας, υποστηρίζοντας πολλαπλές ιεραρχίες αποθήκευσης και μετακινώντας δεδομένα σε γρήγορα επίπεδα πρόσβασης, στη συνέχεια μετακινώντας πίσω προς τα κάτω όταν είναι αδρανής και απαιτείται χώρος. IBM HPSS Τι HPC-era HSM έπρεπε να κάνει καλά Παράλληλοι μετακινητές: πολλαπλές ταυτόχρονες ροές δεδομένων για να διατηρηθεί η συγκεντρωτική ροή υψηλή (επειδή ένα νήμα μετακινητή δεν το κόβει). High-bandwidth staging: disk caches/staging layers sized and tuned to match compute and I/O peaks. Μεσαίου μεγέθους μεταδεδομένα + επιλογή πολιτικής: το σύστημα πρέπει να βρίσκει τα αρχεία υποψηφίων γρήγορα, χωρίς να ξοδεύει όλη την ημέρα σκεπτόμενος γι 'αυτό. Ενσωμάτωση ροής εργασίας: προγραμματιστές παρτίδων, χώροι έργου, αρχείο έναντι μηδέν και προβλέψιμη συμπεριφορά ανάκλησης - επειδή η επιστήμη τρέχει με προθεσμίες και καφέ. Representative products in the 1990s HPC “mass storage” lane NSL UniTree - περιγράφεται στις διαδικασίες HPC ως ενεργώντας όπως ένας εικονικός δίσκος, αυτόματα μετεγκατάσταση αρχείων σε φθηνότερη αποθήκευση μέσω μιας στρατηγικής μετακίνησης προγραμματιζόμενης. SGI DMF (Data Migration Facility) - τοποθετείται ως ένα αυτοματοποιημένο σύστημα διαχείρισης αποθήκευσης επιπέδου που δημιουργεί και διαχειρίζεται αυτόματα ένα περιβάλλον εικονικής αποθήκευσης επιπέδου, χειρίζοντας τη μετανάστευση και την ανάκληση ως μέρος των κανονικών λειτουργιών. EMASS FileServ / VolServ - εμφανίζεται σε μεγάλο βαθμό στο έργο της εποχής της NASA ως μια ιεραρχική οικογένεια μαζικής αποθήκευσης που παρέχει διαχείριση αποθήκευσης / "περιοχής αρχείων", σε συνδυασμό με ένα κεντρικό επίπεδο όγκου / μέσων για αυτοματοποίηση βιβλιοθηκών (η πλευρά του "ρομπότ wrangler" του πλαισίου). NAStore (NASA Ames in-house HSM) - μια εσωτερική προσπάθεια HSM που η NASA αξιολόγησε απευθείας έναντι εμπορικών εναλλακτικών λύσεων όπως το FileServ, το DMF και το UniTree, το οποίο σας λέει πόσο στρατηγικός (και ανταγωνιστικός) ήταν αυτός ο χώρος στη δεκαετία του '90. Why this era matters: Αυτό είναι το σημείο όπου το HSM σταματά να μοιάζει με την «υπηρεσία πληροφορικής» και αρχίζει να μοιάζει με βασική επιστημονική υποδομή - επειδή στο HPC, η αποθήκευση δεν είναι μια ντουλάπα. Late 1990s through the 2010s: stubs, DMAPI, clustered file systems, and enterprise sprawl This is the era where HSM stopped being a niche “supercomputer thing” and turned into something normal people had to run—across messy fleets of UNIX, Windows, tape, disk, and (eventually) object targets. The big shift wasn’t a new idea. It was integration: better file-system hooks, better policy engines, and storage platforms that finally accepted they were part of a bigger workflow. This is the era where HSM stopped being a niche “supercomputer thing” and turned into something normal people had to run—across messy fleets of UNIX, Windows, tape, disk, and (eventually) object targets. The big shift wasn’t a new idea. It was integration: better file-system hooks, better policy engines, and storage platforms that finally accepted they were part of a bigger workflow. UNIX and friends: DMAPI, policy engines, and real automation On UNIX, HSM matured because file systems and clustered/parallel designs started giving HSM what it always wanted: Κοινός χώρος ονομάτων (μία προβολή αρχείων, όχι «η γνώμη αυτού του οικοδεσπότη») Centralized policy evaluation (one ruleset, not 40 snowflakes) Coordinated movers (so recalls/migrations don’t fight each other) Fewer hilarious edge cases where a single server thinks it owns the universe IBM Storage Scale / General Parallel File System (GPFS) is a good example of the “policy engine becomes first-class” pattern—rules select files and trigger actions like placement and migration. And when you bolt it to IBM High Performance Storage System (HPSS) via the GPFS HPSS Interface (GHI), you get the late-90s/2000s reference architecture: file system emits events, a daemon handles them, movers push/pull data to deep archive under Information Lifecycle Management (ILM) control. Άλλα προϊόντα HSM που ταιριάζουν σε αυτή τη φάση του συστήματος αρχείων UNIX/clustered: — classic UNIX HSM architecture (stubs, policies, movers, tape integration) that was widely used in research/media environments. Sun SAM-QFS / Oracle HSM (Data Migration Facility) — strongly present in HPC and “big archive” shops; file-centric HSM with serious mover plumbing. SGI DMF (TSM) for Space Management (later Spectrum Protect for Space Management) — enterprise-grade HSM-style migration/purge/recall integrated with broader data protection tooling. IBM Tivoli Storage Manager Quantum StorNext Storage Manager - στα μέσα μαζικής ενημέρωσης / ψυχαγωγίας και στις μεγάλες μη δομημένες ροές εργασίας, έχει γίνει μια λύση "κρατήστε το online-ish, αλλά πληρώστε τιμές αρχειοθέτησης". — by the 2000s, parallel file systems like Lustre normalized the idea that “hot” lives on the file system and “cold” lives behind an HSM connector. Lustre HSM ecosystems Windows: HSM grows a second head (and a lot of opinions) Το Windows HSM είναι απολύτως αληθινό, αλλά πάντα είχε περισσότερη ενέργεια "παρακαλώ μην κουνήσετε τα χειριστήρια αρχείων μου" από το UNIX. Το DiskXtender (OTG → Legato → EMC era) είναι η κανονική ιστορία των Windows HSM: stubs / placeholders στο NTFS, αυτόματη μετανάστευση αδρανών αρχείων και διαφανής ανάκληση. (Η ίδια βασική συμπεριφορά με το UNIX HSM, μόνο με περισσότερους τρόπους για τις εφαρμογές και τους σαρωτές να ανακαλέσουν τυχαία το αρχείο σας.) Το IBM HSM για Windows είναι ένα άλλο ξεκάθαρο παράδειγμα: το HSM για το Σύστημα Αρχείων Νέας Τεχνολογίας (NTFS) με συμπεριφορά stub/recall, με στόχο να καταστήσει τις μετοχές αρχείων των Windows επιζήμιες χωρίς να αγοράζει άπειρη πρωτογενή αποθήκευση. Enterprise sprawl: HSM ideas leak into “adjacent” domains From the 2000s into the 2010s, the industry also started solving HSM-shaped problems in non-traditional places: Email/groupware archiving (ex: ) — lifecycle policies applied to mail stores. Zarafa Archiver Compliance + tiering platforms (ex: ) — rule-based movement plus retention behavior. PoINT Storage Manager Heterogeneous data movers (ex: ) — “move cold data to cheaper tiers” across mixed file systems/object/tape. Moonwalk Αρχειοθέτηση Zarafa PoINT Storage Manager Moonwalk Αλλά είναι σαφώς στον ίδιο εξελικτικό κλάδο: πολιτική κίνησης, μακροπρόθεσμη διατήρηση και διατήρηση της πρόσβασης προβλέψιμη ενώ η αποθήκευση γίνεται φθηνότερη ανά terabyte και πιο περίπλοκη ανά περιβάλλον. If you want, I can also add a tight one-paragraph “what changed operationally” closer for this section (stub storms, recall throttling, namespace governance, and why clustered metadata made the whole thing less fragile). 2010–2020: Policy Engines, Cloud Tiers, and the Death of “Just Buy More Disk” NAS / file platforms that added object/cloud tiering (2015–2020) — policy-based movement/tiering from OneFS (NFS/SMB) to object targets like S3/Azure (and OneFS-to-OneFS cloud). This is basically “HSM for NAS admins who don’t want to say HSM.” Dell EMC Isilon / PowerScale CloudPools — ONTAP feature that keeps hot data on SSD and tiers colder data to an object store (public or private), driven by policy. NetApp FabricPool Vendor-neutral policy engines for unstructured data (2013–2020) — file analytics + policy-driven tiering/“right placing” of unstructured data across storage systems (file and object). Great example of HSM moving up the stack into “data management.” Komprise Intelligent Data Management — policy-based NAS file migration/tiering; later versions explicitly talk about S3-compliant storage support, which makes it a good “bridge to object” entry in this era. Data Dynamics StorageX Το StrongLink είναι μια μηχανή πολιτικής δια-πλατφόρμας που μπορεί να ταξινομήσει / αντιγράψει / μετακινήσει σε διάφορους τύπους αποθήκευσης. μέχρι το 2020, θα ωθήσει ρητά τη διαχείριση βασισμένη σε πολιτικές LTFS + σε όλες τις σιλό (πολύ «σύγχρονο HSM»). Tape gets modern interfaces (2015–2020) Το IBM Spectrum Archive (LTFS) - η προσέγγιση "band as a file system" που έγινε ένα κοινό δομικό στοιχείο για ενεργά σχέδια αρχείων στη δεκαετία του 2010 (συχνά σε συνδυασμό με μηχανές πολιτικής υψηλότερου επιπέδου). QStar Archive Manager + Network Migrator - παρουσιάζει το αρχείο πίσω από τις μετοχές αρχείων ή τα δοχεία S3 και χρησιμοποιεί τη μετανάστευση βάσει πολιτικής για να ωθήσει τα κρύα δεδομένα σε χαμηλότερα επίπεδα κόστους (μάντρα / αντικείμενο / σύννεφο). — high-performance archiving/migration platform for massive unstructured data across heterogeneous storage; fits well in HPC/media “petabytes + billions of files” conversations. Atempo Miria Cloud-adjacent “stub & tier” services (late 2010s) Azure File Sync (Cloud Tiering) – διαχωρίζει ρητά το ονομαστικό χώρο από το περιεχόμενο (συμπτωματική συμπεριφορά) και ταξινομεί το περιεχόμενο αρχείων στο cloud με βάση τις πολιτικές ελεύθερου χώρου και ημερομηνίας. — early 2010s example of “use cloud as the capacity tier,” long before everyone pretended they invented hybrid tiering. Microsoft StorSimple (hybrid storage appliances) On-prem S3 object platforms that leaned into lifecycle (2015–2020) Είναι καλό να αναφερθούν ως for modern HSM/lifecycle systems: Στόχοι — lifecycle policies / auto-tiering patterns in S3-land. Cloudian HyperStore — S3 lifecycle policy management shows how object platforms absorbed “HSM-like” automation. Scality (RING/Artesca lifecycle tooling) The 2020s: HSM doesn’t die — it gets absorbed into object and cloud semantics In the 2020s, HSM didn’t disappear. It got Οι σύγχρονες πλατφόρμες αντιμετωπίζουν όλο και περισσότερο το tiering ως , όχι ένα ξεχωριστό "προϊόν HSM" που εγκαθιστάτε, προσεύχεστε και στη συνέχεια αποφύγετε να αγγίζετε για πέντε χρόνια. assimilated native capability Αυτό που ήταν μια ιεραρχία Τώρα φαίνεται , driven by , , and Η ίδια αποστολή, διαφορετικά ρούχα. disk → nearline → tape hot → cool → cold → archive lifecycle rules storage classes API-first workflows What “modern HSM” looks like now (on-prem and cloud): transition based on age, tags, prefix, versions, or compliance rules. Lifecycle policies are built into object storage Οι τάξεις αποθήκευσης στο cloud + οι κανόνες μετάβασης καθίστανται η ιεραρχία: η πλατφόρμα αποφασίζει πού ζει το «ψυχρό» και πόσο επώδυνη θα είναι η ανάκληση (αργή + κόστος). , often expressed as config, rules, or JSON—less “the one admin who knows,” more “repeatable automation.” Policy engines are everywhere the control plane shifted. Instead of POSIX stubs and DMAPI events, you’re dealing with . Recall isn’t “open() blocks for a bit.” It’s “restore job, wait window, then access.” Why this matters: object metadata, restore workflows, and billing-aware decisions Cloud & object: HSM becomes “lifecycle” This is where the big public platforms normalized the pattern: Το Amazon S3 Lifecycle μεταβάλλει αντικείμενα μεταξύ των τάξεων, συμπεριλαμβανομένων των επιπέδων αρχειοθέτησης. does the same across hot/cool/cold/archive. Azure Blob lifecycle brings similar semantics to S3-compatible private clouds. Ceph RGW lifecycle + storage classes Η γραμμή: οι πολιτικές κύκλου ζωής είναι , with the bonus feature of “your finance team now gets to participate.” HSM by another name On-prem vendors meet that world halfway (and sometimes sprint into it) A lot of modern “archive” stacks are basically HSM outcomes with object-native interfaces: : positioned as a modern scale-out approach aimed at the scaling pain points of older mass-storage / HSM architectures—policy, lifecycle, and massive namespace management without the classic bottlenecks. Versity ScoutAM / ScoutFS : S3-oriented object storage that plays nicely in “object as the capacity tier” designs, including cold-storage handling patterns aligned with S3 semantics. Quantum ActiveScale Spectra Logic (StorCycle + BlackPearl): οργάνωση κύκλου ζωής / πολιτικής συν μια εμπρόσθια πόρτα βαθιάς αρχειοθέτησης με αντικείμενο (συχνά υποστηριζόμενη από ταινία), η οποία είναι βασικά HSM μεταφρασμένη στη σύγχρονη γλώσσα API. GRAU DATA XtreemStore: προσέγγιση “deep archive + object semantics” – οικονομία ταινίας με σύγχρονα πρότυπα πρόσβασης, δείχνοντας πώς το επίπεδο αρχείου παρουσιάζεται όλο και περισσότερο ως S3/object και όχι μόνο POSIX. Other 2020s “HSM-type” products worth name-dropping If you want this section to feel complete, these fit naturally: File/NAS platforms adding object tiering (HSM baked into the filesystem) NetApp FabricPool Dell EMC Isilon και PowerScale CloudPools Qumulo / παρόμοιες σύγχρονες πλατφόρμες NAS (διαφέρει ανάλογα με το σύνολο χαρακτηριστικών, αλλά το θέμα είναι "πολιτική + στόχος επιπέδου") Policy engines that sit above storage (HSM becomes “data management”) Εργαλεία τύπου Komprise, StrongLink, Data Dynamics που αναλύουν, ταξινομούν και μετακινούν μη δομημένα δεδομένα σε ετερογενείς στόχους (NAS ↔ object ↔ cloud ↔ tape gateways). Tape/object gateways and archive orchestration , , and similar “front end the archive, automate the moves” stacks that bridge file workflows into object/tape-backed retention. QStar Atempo **So no—HSM didn’t vanish. \ It just stopped wearing a name tag that says “HSM,” because “Lifecycle Management” sounds like something you can put in a slide deck without getting heckled. How parallel and clustered file systems supercharged HSM How parallel and clustered file systems supercharged HSM Το αρχικό μοντέλο προέβλεπε μια κατά κύριο λόγο μοναδική φιλοξενούμενη κοσμοθεωρία: ένας διακομιστής αρχείων, ένας χώρος ονομάτων, ένα σύνολο μετακινητών και ένας πληθυσμός χρηστών που Δεν «ανακαλούσε» το πρωί της Δευτέρας σαν να ήταν πυροσβεστική. politely At scale—especially in HPC and multi-department enterprise environments—HSM hit the same predictable walls: The classic HSM bottlenecks (a greatest-hits album) Ο πόνος του συντονισμού των μεταδεδομένων: Το HSM βασίζεται βασικά στα μεταδεδομένα.Δεν μπορείτε να μετακινήσετε αυτό που δεν μπορείτε να βρείτε και δεν μπορείτε να θυμηθείτε με ασφάλεια εάν πολλοί πελάτες διαφωνούν σχετικά με την κατάσταση (“online”, “offline”, “partial”, “staged”, “stubbed”, κ.λπ.). a single workflow change (new analysis job, crawler, antivirus scan, user running find / -type f) could trigger mass recalls. The archive tier doesn’t care that you’re impatient. Recall storms: early designs often had a small number of mover hosts. That’s cute until your compute fabric can read faster than your movers can stage. Single-node mover ceilings: Διανεμημένα πρότυπα πρόσβασης για τα οποία δεν δημιουργήθηκαν πολιτικές: «Τέλος χρόνος πρόσβασης» είναι μια τρομερή εισαγωγή πολιτικής όταν 2.000 κόμβοι αγγίζουν ένα αρχείο μία φορά το καθένα σε μια έκρηξη. Parallel and clustered file systems didn’t magically “fix” HSM. What they did was να του δώσει τα πρωτόγονα που πάντα χρειαζόταν. turn HSM from a fragile add-on into a native capability What clustered/parallel file systems changed 1) A real shared namespace (one truth, not 50 interpretations) Σε ένα συσσωρευμένο σύστημα αρχείων, κάθε πελάτης δεν διατηρεί τη δική του φαντασία σχετικά με την κατάσταση του αρχείου. Υπάρχει ένας χώρος ονομάτων, ένα σύνολο χαρακτηριστικών και μια συνεπής άποψη για το αν τα δεδομένα είναι οικεία, απομονωμένα, μετεγκατασταμένα ή σταθμευμένα. That matters because HSM is basically a : state machine Is the file resident? Είναι μερικώς κατοικημένη; Υπάρχει κάποιο στήθος; Μήπως είναι σε ανάμνηση; Is it pinned? Is it eligible for migration? Clustered file systems make that state . authoritative 2) Centralized policy evaluation at scale Οι πολιτικές του HSM είναι μόνο τόσο καλές όσο η ικανότητα του συστήματος να τις αξιολογεί αποτελεσματικά: scan metadata select candidates execute actions track results Με τα συγκεντρωμένα μεταδεδομένα, οι μηχανές πολιτικής μπορούν να λειτουργήσουν ενάντια σε μια παγκόσμια προβολή και να εφαρμόσουν κανόνες με συνέπεια.Η κλίμακα αποθήκευσης της IBM / GPFS είναι ένα καθαρό παράδειγμα: οι κανόνες πολιτικής αξιολογούν τα χαρακτηριστικά αρχείων και στη συνέχεια ενεργοποιούν ενέργειες όπως η τοποθέτηση, η μετανάστευση και η επιλογή της ομάδας. across storage pools, not “hope the right server runs the right script.” evaluate → select → act 3) Distributed movers (throughput scales with the cluster) Once you stop treating movers as a couple of “special servers,” you can scale them: Περισσότερες μετακινήσεις more parallel streams Καλύτερο συγκεντρωτικό εύρος ζώνης fewer hot spots In HPC, this is everything. If your archive tier can’t stage fast enough, the compute nodes sit idle. That’s not an IT problem—that’s a “we’re lighting money on fire” problem. Τα περιβαλλοντικά συστήματα επιτρέπουν επίσης : you can rate-limit recalls, schedule migrations in off-peak windows, and avoid letting one project’s workflow melt the system. throttling and fairness 4) Better event hooks and workflow integration Η άλλη σημαντική βελτίωση είναι —HSM responding to , not just periodic scans. event awareness what users do DMAPI-style event models (where the file system generates events like open/read on migrated files) let HSM do: (“you touched it, we’ll stage it”) transparent recall (queueing, throttling, priority) controlled recall έξυπνη πολιτική (ανίχνευση καυτών εκρήξεων έναντι μακροπρόθεσμης επαναχρησιμοποίησης) Αυτό είναι όπου το σύστημα γίνεται λειτουργικά υγιές: σταματάτε να βασίζεστε αποκλειστικά σε χρονοδιαγράμματα και αρχίζετε να αντιδράτε σε πραγματικά πρότυπα πρόσβασης. The “true hierarchy” pattern: file system + deep archive integration Once you have clustered metadata + policy + events, you can build cleaner hierarchies where the file system is the user-facing layer and the archive system is the deep tier. That’s exactly what the pattern demonstrates: GPFS generates DMAPI events, an event daemon processes them, and movers push/pull data to under an ILM framework. In practice, GPFS provides the namespace and policy control plane, while HPSS provides the deep archive and tape-scale logistics. GPFS/HPSS Interface (GHI) HPSS What this enabled in the real world (the part people actually care about) Parallel/clustered file systems didn’t just make HSM faster. They made it : less fragile Λιγότερες ασυνέπειες σχετικά με το «ποιος κατέχει αυτό το κράτος αρχείου;» Καλύτερος έλεγχος των καταιγίδων ανάκλησης (παρακολούθηση + τράβηγμα + προτεραιότητα) Policy engines that operate across the whole namespace A path to scale bandwidth by scaling movers and network, not by begging one server to work harder Και αυτός είναι ο λόγος για τον οποίο το HSM επέζησε στη δεκαετία του 2020: όταν οι συσσωρευμένες πλατφόρμες έκαναν πολιτική + μεταδεδομένα + μετακινητές συνεπείς, το HSM σταμάτησε να είναι ένα bolt-on και άρχισε να είναι ένα —even when the backend tier became object storage or cloud instead of tape. foundational pattern UNIX vs Windows: same goal, different pain UNIX vs Windows: same goal, different pain Στο χαρτί, το UNIX και το Windows HSM ακολουθούν το ίδιο αποτέλεσμα: Στην πράξη, οι δύο κόσμοι εξελίχθηκαν με διαφορετικούς μηχανισμούς – και διαφορετικούς τρόπους αποτυχίας – επειδή η σημασιολογία των αρχείων και τα οικοσυστήματα εφαρμογών τους συμπεριφέρονται πολύ διαφορετικά. keep the namespace “whole,” push cold data to cheaper tiers, and recall it when needed UNIX HSM: predictable semantics, better hooks, fewer surprises (usually) UNIX-style HSM tends to work well because it can lean on a few friendly realities: 1) File system event models and hooks Τα περιβάλλοντα UNIX είχαν ιστορικά ισχυρότερα σημεία ενσωμάτωσης «αυτό το αρχείο άγγιξε» – σκεφτείτε event models where the file system can emit events when a process opens/reads a migrated file. That enables a clean pattern: DMAPI-style user opens file file system notices it’s offline/stubbed HSM παίρνει ένα γεγονός Ανακαλύπτεται / απειλείται file becomes resident again Αυτός είναι ο λόγος για τον οποίο οι υλοποιήσεις UNIX/HPC HSM συχνά αισθάνονται πιο «εγγενείς» στην πλατφόρμα: η διαδρομή ανάκλησης μπορεί να συνδεθεί στενά με τη συμπεριφορά του συστήματος αρχείων αντί να είναι ένα πρόγραμμα οδήγησης φίλτρου. 2) “Stub + recall” fits POSIX expectations better Τα εργαλεία POSIX-ish γενικά ανέχονται την έννοια ότι: stat() works even if the file’s data blocks aren’t local permissions/ownership behave consistently errors are interpretable (“file not resident,” “staging,” etc.) HPC workflows can be structured to (pre-stage) before compute runs stage explicitly Ακόμη και όταν είναι ενοχλητικό, είναι τουλάχιστον Οι διαχειριστές του UNIX μπορούν επίσης να το επεξεργαστούν με σχετική εμπιστοσύνη, επειδή το εργαλείο UNIX βασίζεται στην υπόθεση ότι η αποθήκευση μπορεί να είναι αργή, απομακρυσμένη ή παροδική. coherent 3) Control knobs are aligned with ops realities UNIX/HPC HSM stacks commonly give you operational levers that matter: recall throttling Πολιτικές προετοιμασίας / Stage Policies Ποτέ μετανάστευση / Never migrate flags πολιτικές βάσει έργου ανά μονοπάτι, ιδιοκτήτη, ομάδα, σύστημα αρχείων Αυτό καθιστά ευκολότερη την εκτέλεση του HSM ως μέρος μιας μεγαλύτερης ροής εργασίας και όχι ως προσωπικό καθαρισμού μετά το γεγονός. Windows HSM: the same concept, but the ecosystem fights you Το Windows HSM λειτουργεί, αλλά πρέπει να επιβιώσει σε ένα περιβάλλον όπου πολλά λογισμικά υποθέτουν —even when it’s hosted on a file server and the “disk” is a tape library in a trench coat. storage is always fast and always local 1) Applications often assume fast random access forever Πολλές εφαρμογές των Windows (και πολλά εξαρτήματα τρίτων) συμπεριφέρονται ως εξής: “Open file” implies “instant read” Πολλά μικρά τυχαία αναγνώσματα frequent metadata probing Καμία ανοχή για την πολυλεπτή καθυστέρηση ανάκλησης That’s rough when your “cold tier” is tape or deep archive. UNIX/HPC users expect “stage first.” Windows users expect “it’s a file, therefore it should open.” Those are not compatible religions. 2) The hidden villains: indexers, AV scanners, and ‘helpful’ background services Windows environments are full of well-meaning automation that touches files just enough to trigger recalls: crawling a share Indexing services scanning everything it can see Antivirus doing “light reads” eDiscovery / DLP / compliance agents enumerating and verifying files Backup/DR tooling In HSM land, “light touch” can still equal “recall the entire file.” This is where admins learn to fear anything that does recursive scans. 3) Backup software + stubs = confusion (unless you’re careful) Stub files and placeholders are central to Windows HSM. But backup systems can: δημιουργία αντιγράφων ασφαλείας αντί για τα δεδομένα (κακό) trigger υπενθυμίζει για να δημιουργήσετε αντίγραφα ασφαλείας πλήρους περιεχομένου ( χειρότερα: θύελλα υπενθύμισης) mis-handle reparse points / offline attributes depending on vendor So Windows HSM almost always requires : explicit backup integration planning decide whether backups operate on the primary tier only whether backup is allowed to trigger recall αν το αρχειοθετημένο περιεχόμενο προστατεύεται ξεχωριστά στο επίπεδο αρχείου 4) “Transparent recall” is technically true… operationally messy IBM’s documentation for Windows HSM is very explicit that it supports Αυτός είναι ο βασικός στόχος της εμπειρίας του χρήστη. The catch is that transparency can be a trap: users and applications can unknowingly trigger recalls at scale because nothing “looks” different in Explorer. stubs/placeholders and transparent recall behavior Practical bottom line: where each platform shines UNIX HSM is usually best when: workloads are batch/HPC/media pipeline Μπορείτε να προετοιμάσετε ή να προγραμματίσετε policies can be aligned to projects, paths, and compute workflows clustered/parallel file systems provide strong hooks and metadata scale Windows HSM is usually best when: the goal is file-share capacity relief recall volume is moderate and predictable you can tightly control indexers/AV/backup behaviors the organization accepts that “archive tier” means “slower, sometimes a lot slower” What changes when cloud storage shows up? What changes when cloud storage shows up? Cloud doesn’t kill HSM. It . changes who’s driving Το κλασικό HSM ζούσε στο κέντρο δεδομένων σας: ήσασταν ιδιοκτήτες των επιπέδων, της ρομποτικής, των κινητήρων, της ουράς ανάκλησης και του χώρου πολέμου «γιατί η σκηνή είναι αργή». into the storage service itself—and your “tiers” become Με και . HSM control plane shifts upward storage classes lifecycle policies restore workflows In other words: the same game, but now the referee is also your invoice. 1) HSM becomes “lifecycle + class transitions” Instead of “disk → tape” being a local design choice, cloud platforms formalize the hierarchy as and let you define : classes transition rules Μεταβάσεις κατηγορίας αποθήκευσης («μετά από X ημέρες, μετακίνηση σε φθηνότερα επίπεδα») based on age/prefix/tags/versions Lifecycle rules Κλειδαριές διατήρησης και διακυβέρνησης (αμετάβλητη, νομική κατοχή, κλειδαριά αντικειμένου - ανάλογα με την πλατφόρμα) This is textbook HSM behavior, just expressed as platform policy. For example, can automatically transition objects to archival tiers, and can transition blobs across hot/cool/cold/archive in a similar rule-driven model. Amazon S3 Lifecycle Azure Blob lifecycle management 2) “Recall” becomes a restore workflow (and it’s no longer just “slow”… it’s a process) In classic HSM, recall usually meant: queue the request, fetch from tape, stage to disk, let the app proceed. The pain was mostly time. Στο cloud, η υπενθύμιση είναι συχνά μια ρητή Με : restore operation (API call / lifecycle action / console workflow) A restore request Μια περίοδος αναμονής (οι ώρες μπορεί να είναι κανονικές στα επίπεδα αρχείου) Ένα προσωρινό παράθυρο προσβασιμότητας (μερικές φορές καθορίζετε πόσο καιρό θα πρέπει να αποκατασταθεί) Πιθανές χρεώσεις ανάκτησης και χρεώσεις αίτησης Έτσι, η παλιά σας «παρακολούθηση της ταινίας» γίνεται Τα επίπεδα κύκλου ζωής + αρχειοθέτησης του S3 είναι ένα καλό παράδειγμα: μπορείτε να μεταφέρετε αντικείμενα σε κατηγορίες αρχείων, αλλά και να κληρονομήσετε τη σημασιολογία αποκατάστασης και τους λειτουργικούς περιορισμούς αυτών των επιπέδων. a workflow dependency 3) Metadata and inventory suddenly matter a lot more In traditional HSM, “what tier is it on?” was internal state. In cloud/object systems, you tend to manage by: Μεταδεδομένα αντικειμένων / tags Prefixes Inventory reports Αποθήκευση ανάλυσης Versioning state Why? Because your policy engine is operating on object attributes, not POSIX file-system events. If you can’t the state cheaply (inventory/metrics), you’ll make bad lifecycle decisions—or you’ll discover them on the bill. see 4) Billing becomes an HSM constraint (and sometimes the dominant one) Οι παλιές αποφάσεις του HSM ήταν κυρίως: media cost Επίδοση operational burden Το cloud προσθέτει: Κόστος ανάκτησης Αίτηση κόστους Ποινές πρόωρης διαγραφής (μερικά επίπεδα αρχείων) κόστος δικτύου (ειδικά διαπεριφερειακό ή εκτός cloud) API rate limits and per-request overhead That changes behavior. Teams start asking questions they never asked on-prem: "Αξίζει να το αποκαταστήσουμε αυτό ή πρέπει να αναπροσαρμοστούμε από την πηγή;" «Μπορούμε να κάνουμε τοπική σκηνή και να επαναφέρουμε παρτίδες;» “Should we replicate, version, or do we pay twice forever?” Το αρχείο σας δεν είναι πλέον ένα παθητικό «φθηνό υπόγειο». 5) Hybrid becomes the default architecture Τα περισσότερα καταστήματα δεν αλλάζουν την αλλαγή από το "HSM" στο "cloud". On-prem file system + cloud/object as capacity tier Cloud-native αντικείμενο + on-prem cache/edge επίπεδο Πύλες ταινίας / αντικειμένου που παρουσιάζουν διεπαφές S3 διατηρώντας παράλληλα την οικονομία της ταινίας Αυτός είναι ακριβώς ο λόγος για τον οποίο οι σύγχρονοι προμηθευτές προτιμούν την «διαχείριση κύκλου ζωής» αντί για την «HSM»: τα επίπεδα μπορούν να είναι οπουδήποτε και η ορχήστρα εκτείνεται σε πολλαπλά επίπεδα ελέγχου. 6) Ceph RGW and S3-compatible ecosystems: cloud semantics without hyperscalers In Ceph RGW and other S3-compatible environments, lifecycle-driven transitions exist as well. The mechanics can vary by implementation (and sometimes include constraints like one-way transitions or limited class behaviors), but the underlying shift is the same: εκτελείται από την πλατφόρμα. policy is expressed in object terms The big operational shift (the part your app teams will absolutely notice) Cloud turns “recall latency” into a three-part problem: Χρόνος (επαναφορά καθυστέρησης) (retrieval + request + possibly egress) Money (who triggers restore, how long it stays restored, what workflows depend on it) Process That’s why application teams suddenly care «Σε τι επίπεδο βρίσκεται αυτό;» Στο σύννεφο, οι επιλογές των επιπέδων χτυπούν , and nobody likes surprises—especially the kind that show up as a four-figure line item labeled “retrieval.” Πολλά performance and budget at the same time Sidebar: Cloud HSM Anti-Patterns (a.k.a. how to accidentally finance your provider’s next yacht) Sidebar: Cloud HSM Anti-Patterns (a.k.a. how to accidentally finance your provider’s next yacht) Here are Πολύ συνηθισμένοι τρόποι δημιουργίας ομάδων και που αισθάνονται σαν εκβιασμός (αλλά με καλύτερη UX): six recall storms retrieval bills Let’s just run a recursive scan.” Someone points an indexer, antivirus, DLP tool, or discovery crawler at an object-backed namespace (or file gateway) and it “helpfully” touches everything. If those touches trigger restores/reads, you’ve just scheduled a surprise mass recall. Treating archive like a slower version of standard storage Teams transition data to archive tiers and keep the same application behavior—random reads, lots of small GETs, frequent reprocessing. Archive tiers are not “cheap disk.” They’re a cost/latency contract with consequences. No restore orchestration (aka “YOLO restore”) Restores kicked off ad hoc by users/apps without queueing, throttling, or prioritization. Result: clogged restore pipelines, missed deadlines, and a bill that looks like a phone number. Life-cycle rules without lifecycle governance “After 30 days, shove it to Glacier/Archive” sounds smart until Legal needs it tomorrow, or the workflow still references it weekly. Lifecycle must align with , not wishful thinking. actual access patterns Ignoring minimum storage durations / early deletion penalties Some archive tiers have minimum retention periods. Transitioning too aggressively (or deleting/overwriting too quickly) can trigger charges that make your “savings” evaporate. Egress amnesia The archive data might be cheap to store, but pulling it out—especially cross-region or out of cloud—can be expensive. If your plan is “restore everything back on-prem for processing,” congrats, you’ve invented a budget bonfire. One-line fix mindset: Αντιμετωπίστε το αρχείο cloud σαν ταινία με ένα API: plan restores, batch reads, control scanners, and make lifecycle decisions based on measured access—not optimism. What changes as we move from POSIX to Object Storage? Τι αλλάζει καθώς μετακινούμαστε από το POSIX στο Object Storage; Αυτό είναι το σημείο της ιστορίας όπου πολλά από τα έξυπνα ένστικτα του HSM πρέπει να... ευγενικά αποσυναρμολογηθούν και να ανοικοδομηθούν. Όπου όλα είναι ένα , ο ονομαστικός χώρος είναι ιερός, και η «αναφορά» υποτίθεται ότι είναι διαφανής. , the , και η «αναφορά» είναι συχνά ένα ρητό βήμα της ροής εργασίας. POSIX world file Το namespace είναι προαιρετικό Το API είναι η διεπαφή Ο ίδιος στόχος – τα σωστά δεδομένα, το σωστό επίπεδο, το σωστό κόστος – αλλά η μηχανική και το διανοητικό μοντέλο αλλάζουν σκληρά. POSIX-first HSM (classic): “keep the illusion alive” Το παραδοσιακό HSM είναι χτισμένο γύρω από το συμβόλαιο POSIX: Τα αρχεία και οι κατάλογοι είναι η εμπειρία του χρήστη (move/rename is meaningful) Pathnames are identity Οι άδειες / ιδιοκτησία επιβάλλονται μέσω του συστήματος αρχείων Οι εφαρμογές χρησιμοποιούν το άνοιγμα / ανάγνωση / κλείσιμο και αναμένουν τα δεδομένα να είναι εκεί όταν το κάνουν Έτσι, η κλασική HSM βελτιστοποιεί για ένα πράγμα πάνω απ 'όλα: preserve the illusion that the file is still “right there.” How it does that Stubs/placeholders: το αρχείο εξακολουθεί να υπάρχει στο δέντρο καταλόγου, αλλά το φορτίο χρήσης έχει μεταφερθεί. Διαφανής ανάκληση: αγγίξτε το αρχείο, το HSM το επαναφέρει (συχνά μέσω δεσμών συστήματος αρχείων / συμβάντων). path patterns, uid/gid, project directories, file size, atime/mtime, “don’t migrate these extensions,” etc. Policies are file-centric: The strengths: Minimal app changes (in theory) Users stay productive in familiar tools Λειτουργεί εξαιρετικά για ροές εργασίας που είναι ως επί το πλείστον διαδοχικές και προβλέψιμες Οι αδυναμίες : Stub Storms (δείκτες, crawlers, AV, εργαλεία ασφαλείας) Σκανάρισμα βαρέων μεταδεδομένων σε κλίμακα “Transparency” becomes operational risk when anything touches everything Object-first lifecycle (modern): “stop pretending, start governing” Η αποθήκευση αντικειμένων δεν προσπαθεί να είναι ένα σύστημα αρχείων. Η ταυτότητα είναι συνήθως: API-driven key/value store with metadata Bucket + key (συνήθως ένα ψευδο-διάγραμμα που βασίζεται σε πρόθεμα) Περισσότερα tags/μεταδεδομένα Plus versioning state Κλάση αποθήκευσης / Tier Οι εφαρμογές δεν «ανοίγουν() ένα αρχείο». , often in chunks, often repeatedly, often via distributed clients. GET an object What lifecycle looks like in an object world Οι κινητήρες κύκλου ζωής λειτουργούν σε: (days since creation/last modified) Age Πρόθεμα («όλα κάτω από αυτό το χώρο κλειδιών») (“Project=NDNP”, “Retention=7Y”, “LegalHold=True”) Tags Εκδόσεις (μη τρέχουσες μεταβάσεις έκδοσης, κανόνες λήξης) Αντί για σπόρους, μπορείτε να πάρετε: (hot → cool → cold → archive) Storage class transitions Επαναφορά ροών εργασίας για τα επίπεδα αρχειοθέτησης (διαφανή βήματα «επαναυδάτωσης») Μερικές φορές μοτίβα αντιγραφής-επαναφοράς (επαναφορά σε νέα τοποθεσία / κατηγορία) Object storage is less “transparent recall” and more “stateful data governance.” The big differences that matter operationally 1) Namespace identity changes (paths vs keys) In POSIX, the path is -Το επώνυμο και οι κινήσεις έχουν νόημα και συνήθως διατηρούν την ταυτότητα. everything the “directory” is usually just a key prefix convention «Rename» συχνά σημαίνει αντίγραφο + διαγραφή (ακριβό σε κλίμακα) identity and policy control tend to ride on , not directory trees tags/metadata 2) Metadata becomes your control plane Το Classic HSM χρησιμοποιεί τα χαρακτηριστικά αρχείων και τη σάρωση μεταδεδομένων του συστήματος αρχείων. Ο κύκλος ζωής του αντικειμένου βασίζεται σε: Μεταδεδομένα αντικειμένων / tags Έκθεση απογραφής analytics about access patterns, size distributions, version churn Εάν δεν επενδύετε σε Ο κύκλος ζωής γίνεται μαντεία και η μαντεία γίνεται κόστος. inventory + visibility 3) Access patterns shift from stateful IO to stateless requests ΠΕΡΙΕΧΟΜΕΝΑ IO: Ανοιχτό/Διαβάστε/Γράψτε/Κλείστε Πολλοί μικροί έλεγχοι μεταδεδομένων Η διαδοχική ροή είναι κοινή στο HPC/media Το αντικείμενο είναι: Χωρίς κράτος GET/PUT Οι συντάξεις είναι φυσιολογικές Οι παράλληλοι πελάτες είναι κοινοί Ποσοστό αίτησης (και κόστος ανά αίτηση) Αυτό αλλάζει το πώς μοιάζει η «καταιγίδα υπενθύμισης».Στη γη αντικειμένων, δεν είναι «ο καθένας άνοιξε ένα σφυρί».Είναι «ένα εκατομμύριο μικρά GET και αιτήματα αποκατάστασης χτυπήθηκαν ταυτόχρονα». 4) “Recall” changes meaning Στο αρχείο HSM: recall = επαναφορά του αρχείου στο δίσκο και ικανοποίηση του POSIX IO Ο κύκλος ζωής του αντικειμένου: “recall” might mean: from an archive class for temporary access restore into a hotter class permanently rehydrate into a new location/work bucket for processing copy into a POSIX cache via a gateway materialize Έτσι δεν βελτιστοποιείτε πλέον μόνο για την καθυστέρηση. . workflow timing + cost + durability + governance 5) Security and governance models shift Η ασφάλεια του POSIX επιβάλλεται στο επίπεδο του συστήματος αρχείων (UID/GID, ACLs). Η ασφάλεια του αντικειμένου βασίζεται συνήθως σε: Υπάρχουν πολιτικές Πολιτική κλειδιού / bucket policy ACLs αντικειμένου (ανάλογα με την πλατφόρμα) Ελέγχου με βάση τις ετικέτες / τα χαρακτηριστικά Αυτό αλλάζει τον τρόπο με τον οποίο εφαρμόζετε "μόνο αυτή η ομάδα μπορεί να ανακαλέσει / ενυδατώσει" ή "αυτό το σύνολο δεδομένων δεν μπορεί να αφήσει κρύο επίπεδο". 6) Hybrid gateways reintroduce POSIX—but with new failure modes Πολλά καταστήματα χρησιμοποιούν: Πύλη αρχείου πάνω από αντικείμενο Το POSIX Overlays πάνω από το S3 Συσκευές που «μοιάζουν με μας» Αυτό είναι χρήσιμο, αλλά μπορεί να δημιουργήσει ένα χειρότερο σενάριο και των δύο κόσμων: Οι εφαρμογές POSIX συμπεριφέρονται σαν τα πάντα να είναι τοπικά gateway triggers αντικείμενο επαναφέρει / GETs πίσω από τις σκηνές Θύελλα ανάκλησης + Θύελλα αιτήσεων + λογαριασμοί έκπληξης Net effect: HSM becomes less about illusion and more about governance Το κλασικό HSM ήταν συχνά: “Make the file system pretend the data is nearby.” Ο σύγχρονος κύκλος ζωής των αντικειμένων είναι: “Manage where data lives over time, and make access a controlled workflow.” Η διαφάνεια δεν είναι πλέον ο προεπιλεγμένος στόχος - predictability is. What “winning” looks like in the 2020s Τα συστήματα που λειτουργούν καλύτερα σε αυτή τη μετάβαση τείνουν να: Εκθέστε καθαρά τους ελέγχους κύκλου ζωής (ταξίες αποθήκευσης, μεταβάσεις, διατήρηση, συμπεριφορά αποκατάστασης) Παροχή απογραφής + αναλυτικών στοιχείων (έτσι η πολιτική βασίζεται στην πραγματικότητα, όχι στο λαϊκό κείμενο) Ενσωμάτωση με μηχανές ροής εργασίας (εκδηλώσεις, ουρές, αυτοματοποίηση, όρια τιμών) Υποστήριξη υβριδικής πρόσβασης με ασφάλεια (απομνημόνευση / πύλες με φυλακές, όχι "έκπληξη επαναφορά ρουλέτας") Κάντε την κατάσταση ορατή (επίπεδο, κατάσταση αποκατάστασης, συνέπειες κόστους) έτσι ώστε οι εφαρμογές και οι χρήστες να μην πετούν τυφλά So where is HSM headed next? Πού θα πάει το επόμενο HSM; Το μέλλον του HSM δεν είναι «ένα νέο επίπεδο». . a new operating model For decades, HSM was mostly about : μετακινήστε τα κρύα αρχεία από το ακριβό δίσκο, φέρετέ τα πίσω όταν κάποιος το ζητήσει. στη δεκαετία του 2020 και μετά, αυτό είναι το στοίχημα τραπέζι. Ειδικά όταν τα επίπεδα σας καλύπτουν συστήματα αρχείων on-prem, αποθήκες αντικειμένων και τάξεις δημόσιου νέφους. placement how decisions are made, how they’re enforced, and how you prove they’re working Εδώ είναι που πηγαίνει. 1) Policy-as-code: fewer tribal rituals, more repeatable engineering Το μελλοντικό HSM stack μοιάζει λιγότερο με "μια GUI γεμάτη κανόνες που κανείς δεν τολμά να αγγίξει" και περισσότερο σαν : infrastructure code Πολιτικές γραμμένες ως δηλωτικοί κανόνες (συχνά αποθηκεύονται στο Git) Versioned, peer-reviewed, and traceable («Ποιος άλλαξε αυτό και γιατί;») Δοκιμάστηκε σε σχέση με πραγματικά σύνολα δεδομένων ή συνθετικά αποθέματα (“τι θα μεταναστεύσει αυτό αν το ενεργοποιήσουμε;”) Αναπτύχθηκε με σταδιακές αναπτύξεις και σχέδια rollback Αυτό έχει σημασία διότι οι πολιτικές του HSM είναι αποτελεσματικές. Αν τα αντιμετωπίσετε ως εφάπαξ προσαρμογές διαμόρφωσης, θα λάβετε τελικά: production traffic rules Τυχαία μαζική μετανάστευση Η έκπληξη θυμίζει τις καταιγίδες compliance failures Ένα περιστατικό που όλοι θα θυμούνται για πάντα Policy-as-code turns HSM from “admin craft” into . operational engineering 2) Observability becomes non-negotiable (because lifecycle without visibility is just gambling) Το κλασικό HSM συχνά έτρεχε με την ελπίδα και τις προγραμματισμένες εκθέσεις. : telemetry Τι πρέπει να δείτε (συνεχώς): Απογραφή: αριθμοί, μεγέθη, κατανομή ανά κατηγορία / κατηγορία Θέρμανση: συχνότητα πρόσβασης, πρόσφατη πρόσβαση, συμπεριφορά έκρηξης : queue depth, latency percentiles, failure rates Recall behavior Μετακίνηση απόδοσης: σταδιακά bytes/sec, concurrency, bottlenecks Σήματα κόστους: κόστος ανάκτησης, κόστος αίτησης, εκκρεμότητα, ποινές πρόωρης διαγραφής Αποτελέσματα πολιτικής: «Πόσο πραγματικά κινείται αυτή η πολιτική και τι εξοικονομεί;» Και στο έδαφος του νέφους / αντικειμένου, η μη προσαρμογή του δεν είναι απλώς χάσιμο χρόνου - σπαταλάει χρήματα με τρόπο που εμφανίζεται σε ένα μηνιαίο λογαριασμό και τη διάθεση ενός διευθυντή. Ο νέος κανόνας είναι: . tiering decisions must be telemetry-driven, not vibes-driven 3) Workflow integration: “recall” becomes an orchestrated event, not an accident Στο κλασικό HSM, ο χρήστης αγγίζει το αρχείο και το σύστημα το στάδιο. Το μέλλον μοιάζει : event-driven orchestration Επανασύνταξη/Ανυδάτωση με βάση την ουρά προτεραιότητα («αυτή η δουλειά πρέπει να γίνει στις 9 το πρωί, ότι κάποιος μπορεί να περιμένει») Οδηγίες για την αποφυγή καταιγίδων σε όλο το σύστημα Προστατευτικά παράθυρα που συνδέονται με προγραμματιστές εργασιών (HPC) ή επεξεργασία παρτίδων automated notifications (“restore complete,” “data available,” “retry scheduled”) Αντί για «διαφανή ανάκληση», ο στόχος μετατοπίζεται προς : predictable recall Προβλεπόμενη λήξη Προβλέψιμο κόστος Προβλέψιμη συμπεριφορά ροής εργασίας Τα συστήματα που θα κερδίσουν θα αντιμετωπίσουν «την ανάκτηση δεδομένων από το κρύο επίπεδο» σαν ένα πρώτο βήμα του αγωγού - όχι μια απρόβλεπτη παρενέργεια κάποιου που κάνει κλικ σε ένα φάκελο. 4) Business signals become policy inputs (ILM finally earns its keep) Αυτό είναι όπου η ILM παύει να είναι μια φιλοσοφία διαφάνειας και γίνεται πρακτική. Οι αποφάσεις που λαμβάνονται συνδέονται όλο και περισσότερο με Όχι μόνο ο χρόνος πρόσβασης: business events Το έργο κλείνει → μετάβαση σε κρύο/αρχείο δημοσίευση / απελευθέρωση → αναπαράσταση + διατήρηση αμετάβλητα legal hold → lock / block deletion / αλλαγή συμπεριφοράς retention clock starts → lifecycle becomes deterministic τερματίζει τη χρηματοδότηση → επιβάλλει τη στάση αρχειοθέτησης και μειώνει τις δαπάνες ζεστής αποθήκευσης Αλλαγές ευαισθησίας → περιορισμός των διαδρομών πρόσβασης και επανακρυπτογράφηση / επανασημείωση Αυτή είναι η «ενήλικη» έκδοση του HSM: πολιτικές που οδηγούνται από Όχι μόνο τα χρονοδιαγράμματα. meaning 5) A shift in what HSM optimizes for: from “capacity relief” to “governed lifecycle” Η παλιά επιτυχία του HSM έμοιαζε: «Απελευθερώσαμε το 40% του πρωτογενούς δίσκου» Η σύγχρονη επιτυχία του HSM μοιάζει με: «Μπορούμε να αποδείξουμε πού ζουν τα δεδομένα, γιατί είναι εκεί, πόσο κοστίζει, πόσο γρήγορα μπορούμε να τα πάρουμε πίσω και πόσο καιρό πρέπει να τα κρατήσουμε». “we can change policy safely without outages” «Μπορούμε να ικανοποιήσουμε τις απαιτήσεις διατήρησης / αμετάβλητης λειτουργίας χωρίς να διακόπτουμε τις ροές εργασίας» «Μπορούμε να προβλέψουμε και να καλύψουμε τις δαπάνες ανάκτησης» Ο στόχος είναι λιγότερο «να κάνει το δίσκο να φαίνεται μεγαλύτερο» και περισσότερο . govern data over time across multiple storage domains Bottom line Κατώτατη γραμμή Το ILM είναι το «γιατί».Το HSM είναι ακόμα το «πώς». What’s changing is the implementation: HSM is evolving into Και εκφράζεται μέσα από και Περισσότερα από αρχεία. policy-as-code + observability + event-driven workflows lifecycle engines object semantics Και ναι - η μόνη πραγματικά σταθερή σταθερή είναι ότι οι πωλητές θα συνεχίσουν να την μετονομάζουν, επειδή το "HSM" ακούγεται σαν κάτι που θα βρείτε σε ένα μπέιζ ράφι δίπλα σε έναν εκτυπωτή dot-matrix.