Μετάβαση Splunk χωρίς διακοπή λειτουργίας στην inDrive: Από Bare Metal σε AWS SmartStore

Γεια σας, είμαι ο , Engineering Manager στο Κέντρο Επιχειρήσεων Ασφάλειας (Security Operations Center - SOC) της inDrive. Ivan Saakov Σε αυτό το άρθρο, μοιράζομαι την εμπειρία μου και την αρχιτεκτονική πίσω από τη μετεγκατάσταση του Splunk Enterprise από ένα παραδοσιακό on-premises cluster bare-metal με τοπικούς δίσκους στο AWS χρησιμοποιώντας την τεχνολογία SmartStore. Το SmartStore επιτρέπει τη χρήση αποθηκευτικού χώρου συμβατού με S3 για τα warm Splunk buckets, διατηρώντας τα πλήρως αναζητήσιμα. Για να διατηρήσω αυτό το άρθρο εστιασμένο, παραλείπω σκόπιμα τα βασικά βήματα εγκατάστασης και παραμετροποίησης του Splunk Enterprise και επικεντρώνομαι στις ρυθμίσεις που αφορούν ειδικά τη μετεγκατάσταση και είναι πιο σημαντικές. Βασικό επίτευγμα της προσέγγισης που χρησιμοποίησα: Μηδενικός Χρόνος Διακοπής (Zero Downtime): Εισαγωγή (Ingestion): Η ροή δεδομένων δεν διακόπτεται ποτέ. Αναζήτηση (Search): Η αναζήτηση παραμένει συνεχώς διαθέσιμη. SOC: Η ειδοποίηση συνεχίζει να λειτουργεί χωρίς υποβάθμιση. Εμπειρία Χρήστη: Οι χρήστες δεν αντιλαμβάνονται την αλλαγή. Η Υποστήριξη Splunk γενικά συνιστά τη διακοπή της εισαγωγής δεδομένων για αυτόν τον τύπο μετεγκατάστασης. Εγώ παρέκκλινα εσκεμμένα από αυτήν την οδηγία. Σε ένα κρίσιμο περιβάλλον Κέντρου Επιχειρήσεων Ασφάλειας (SOC), η διακοπή της εισαγωγής ή της ειδοποίησης είναι απλά απαράδεκτη. 1. Ορολογία και Αρχιτεκτονική Ορισμοί και συντομογραφίες: CM (Cluster Manager): Ο κόμβος διαχειριστής για το cluster IDX. Compute: Instances Amazon EC2. DS (Deployment Server): Ένας διακομιστής για τη διαχείριση των ρυθμίσεων των endpoints. HF (Heavy Forwarder): Ένας αφιερωμένος κόμβος για την εισαγωγή, ανάλυση και δρομολόγηση δεδομένων από συγκεκριμένες πηγές, όπως APIs, βάσεις δεδομένων και syslog. IDX (Indexer): Ένας κόμβος υπεύθυνος για την ευρετηρίαση και αποθήκευση δεδομένων. Τοπική Αποθήκευση (NVMe): Χρησιμοποιείται αυστηρά ως cache, συμπεριλαμβανομένων των hot buckets και των cached warm buckets. Όχι SmartStore (Πηγή): Το αρχικό cluster Splunk bare-metal. Τοπική αποθήκευση για hot, warm και cold data με κλασική αναπαραγωγή. Απομακρυσμένη Αποθήκευση (S3): Η πηγή αλήθειας. Αποθηκεύει όλα τα warm buckets. Παρέχει ανεξαρτησία υλικού και ανθεκτικότητα δεδομένων μέσω εγγενούς αναπαραγωγής AWS σε Ζώνες Διαθεσιμότητας (Multi-AZ). SH (Search Head): Ένας κόμβος υπεύθυνος για την αναζήτηση και τη συγκέντρωση. SHC (Search Head Cluster): Ένα cluster υψηλής διαθεσιμότητας κόμβων αναζήτησης. SmartStore (Προορισμός): Η αρχιτεκτονική προορισμού στο AWS. 2. Λογική SmartStore Το SmartStore αλλάζει το παράδειγμα αποθήκευσης: Απομακρυσμένη Αποθήκευση (S3): Ένα ενιαίο επίπεδο αποθήκευσης. Ανεξάρτητα από τον Παράγοντα Αναπαραγωγής (Replication Factor) του cluster, μόνο ένα μοναδικό αντίγραφο κάθε bucket αποθηκεύεται στο S3. Αυτό προσφέρει τεράστιες εξοικονομήσεις στο κόστος αποθήκευσης. Indexer: Λειτουργεί ως κόμβος υπολογιστικής ισχύος, ενώ οι τοπικοί του δίσκοι χρησιμοποιούνται αποκλειστικά ως cache αναζήτησης. Ο Cache Manager, ο οποίος εκτελείται στους κόμβους indexer, είναι υπεύθυνος για την έξυπνη διαχείριση του κύκλου ζωής των δεδομένων σε γρήγορους τοπικούς δίσκους NVMe. Η συμπεριφορά του βασίζεται σε δύο μηχανισμούς: Εκκένωση (Eviction): Καθαρίζει επιλεκτικά την cache όταν ο χώρος μειώνεται. Ο αλγόριθμος κατανοεί τους τύπους αρχείων: βαριά δεδομένα όπως αρχεία TSIDX και αρχεία καταγραφής (journal archives) εκκενώνονται πρώτα, ενώ ελαφριά αρχεία υπηρεσίας, όπως φίλτρα bloom (bloom filters), παραμένουν στον δίσκο περισσότερο για να διατηρούνται γρήγορες οι αναζητήσεις. Λήψη (Fetch - Rehydration): Κατά τη διάρκεια μιας αναζήτησης, ο Cache Manager δεν κατεβάζει ολόκληρο ένα bucket από το S3. Κατεβάζει διαφανώς μόνο τα στοιχεία του bucket που απαιτούνται για τη συγκεκριμένη ερώτηση, είτε πρόκειται για μεταδεδομένα, TSIDX ή δεδομένα καταγραφής. Αυτό επιτρέπει σε εντολές όπως η tstats να ολοκληρωθούν χωρίς να κατεβάσουν καθόλου βαριά αρχεία καταγραφής (raw logs). Επιπλέον, ο μηχανισμός Lookahead προκαταλαμβάνει ευριστικά δεδομένα για να αντισταθμίσει την καθυστέρηση του δικτύου. 3. Μέγεθος Υλικού (AWS) Για το SmartStore, η ισορροπία μεταξύ της απόδοσης της CPU και της τοπικής cache είναι κρίσιμη. Η χρήση όγκων EBS στο AWS είναι δυνατή, αλλά στην πράξη είναι συνήθως πιο ακριβή όταν οι απαιτήσεις IOPS και διέλευσης (throughput) είναι συγκρίσιμες. Επιλογή Instance: Οικογένεια i3en Προορισμός: i3en.6xlarge (Storage Optimized). Διέλευση: 150 GB/ημέρα/peer, σύμφωνα με τις συστάσεις Splunk για αυτόν τον αριθμό πυρήνων CPU και RAM. Αποθήκευση: 15 TB NVMe Instance Store (RAID 0). Η πολύ μεγάλη cache επιτρέπει στα hot data να παραμένουν τοπικά, ελαχιστοποιώντας την καθυστέρηση και μειώνοντας το κόστος αιτημάτων S3. Επειδή το S3 περιέχει ήδη ένα αντίγραφο των δεδομένων, δεν υπάρχει ανάγκη για καθρέφτισμα (mirroring) των τοπικών δίσκων με RAID 1 ή 10. Δίκτυο: 25 Gbps. Αυτό είναι κρίσιμο για γρήγορη επαναφόρτιση (rehydration) από το S3 κατά τη διάρκεια βαριών αναζητήσεων. Σημαντική λεπτομέρεια: Εφήμερη αποθήκευση Οι δίσκοι i3en είναι όγκοι Instance Store, συνδεδεμένοι φυσικά στον host. Επανεκκίνηση (Reboot): Τα δεδομένα διατηρούνται. Διακοπή (Stop) / Τερματισμός (Terminate): 100 τοις εκατό των δεδομένων στους τοπικούς δίσκους NVMe καταστρέφονται πλήρως και αμετάκλητα. Αυτό είναι ένα χαρακτηριστικό υλικού του AWS: όταν μια instance EC2 διακόπτεται, οι δίσκοι αποσυνδέονται φυσικά και διαγράφονται κρυπτογραφικά. Αντιμετώπιση: Ενεργοποίηση Προστασίας Τερματισμού (Termination Protection). Ενεργοποίηση Προστασίας Διακοπής (Stop Protection) (EC2 Console -> Actions -> Instance Settings). 4. Παραμετροποίηση Amazon S3 (Production Hardening) 5. Ασφάλεια και IAM: Υβριδική Πρόσβαση Απαιτήσαμε πρόσβαση σε ένα ενιαίο S3 bucket τόσο από το περιβάλλον Πηγής όσο και από το περιβάλλον Προορισμού. Το ακόλουθο σύνολο δικαιωμάτων S3 αποδείχθηκε επαρκές: { "Version": "2012-10-17", "Statement": [ { "Sid": "ListAndLocation", "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": "arn:aws:s3:::splunk-bucket" }, { "Sid": "ObjectRW", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject", "s3:AbortMultipartUpload" ], "Resource": "arn:aws:s3:::splunk-bucket/*" } ] } Υλοποίηση πρόσβασης Προορισμός: Χρησιμοποιήστε έναν IAM Role (Instance Profile). Ποτέ μην αποθηκεύετε κλειδιά πρόσβασης σε EC2. Επικύρωση: sudo -u splunk aws s3 ls s3://splunk-bucket Πηγή: Χρησιμοποιήστε έναν IAM User. Δημιουργία ενός χρήστη υπηρεσίας. Δημιουργία ενός και . access_key secret_key Καθορίστε τα στο . indexes.conf Μετά την ολοκλήρωση της μετεγκατάστασης, ανακαλέστε τα κλειδιά. 6. Εξισορρόπηση Κίνησης (AWS ALB) Η σωστή παραμετροποίηση του ALB είναι κρίσιμη για σταθερή εισαγωγή μέσω του HTTP Event Collector (HEC) και για το Web UI. Ρυθμίσεις Global Listener Connection Idle Timeout: 290 δευτερόλεπτα. Για το HEC, η σημαντική ρύθμιση είναι busyKeepAliveIdleTimeout=300 στην ενότητα [http] του inputs.conf. Το timeout του ALB πρέπει να είναι αυστηρά μικρότερο, ώστε ο load balancer να κλείνει πρώτος τη σύνδεση. Διαφορετικά, ο client θα λάβει 502 Bad Gateway. HTTP/2: Ενεργοποιημένο. Ωστόσο, το HTTP/2 πρέπει να είναι ενεργοποιημένο και από την πλευρά του client για τους αποστολείς που ωθούν κίνηση προς το ALB. Στην πράξη, οι περισσότεροι αποστολείς HEC εξακολουθούν να χρησιμοποιούν HTTP/1.1. Target Groups A. HEC (IDX) Health Check: /services/collector/health επαληθεύει ότι το HEC endpoint είναι ζωντανό και εξυπηρετεί αιτήματα σε επίπεδο εφαρμογής, κάτι που είναι καλύτερο από έναν απλό έλεγχο TCP. Stickiness: ON (βασισμένο σε cookie) αν useACK=true. OFF αν useACK=false. B. Web GUI (SHC) Stickiness: ON (βασισμένο σε διάρκεια). Το Web UI είναι stateful: τόσο η συνεδρία χρήστη όσο και τα αντικείμενα εργασιών αναζήτησης (search job artifacts) συνδέονται με έναν συγκεκριμένο κόμβο SH. Επομένως, η stickiness πρέπει να είναι ενεργοποιημένη στο ALB, αλλιώς οι χρήστες θα εναλλάσσονται μεταξύ κόμβων SH και θα αντιμετωπίζουν σφάλματα ή θα χρειάζεται να ξανασυνδεθούν. 7. Εγκατάσταση Υποδομής: Cluster Multisite Για να επιτύχω μετεγκατάσταση μηδενικού χρόνου διακοπής, χρησιμοποίησα μια προσωρινή αρχιτεκτονική στην οποία δύο clusters Splunk εκτελούνται παράλληλα, καθένα διαχειριζόμενο από τον δικό του Cluster Manager: Source CM: Διαχειρίζεται επί του παρόντος το υπάρχον cluster bare-metal. Target CM: Διαχειρίζεται το νέο cluster IDX multisite στο AWS. 8. Αρχιτεκτονική Τοποθεσίας (Multisite) Σε μια διαμόρφωση SmartStore + Multisite, είναι κρίσιμο να εκχωρηθούν σωστά οι ρόλοι στις τοποθεσίες (sites). Αρχιτεκτονική: site1: Ζώνη Διαθεσιμότητας AWS A (IDX) site2: Ζώνη Διαθεσιμότητας AWS B (IDX) site0: SHC Γιατί Site 0; Αν τοποθετήσετε το SH στο site1, το Splunk ενεργοποιεί αυτόματα το Search Affinity, προσπαθώντας να διαβάσει δεδομένα από τοπικούς peers. Στο SmartStore, αυτό είναι αντιπαραγωγικό: η τοπική cache μπορεί να είναι άδεια ενώ το απαιτούμενο bucket βρίσκεται στο S3. Η επιβολή site affinity παρεμβαίνει στη λογική του Cache Manager και αυξάνει την καθυστέρηση. Η τοποθέτηση του SHC στο site0 απενεργοποιεί αυτή τη συμπεριφορά και επιτρέπει στο SHC να ζητήσει δεδομένα από οποιονδήποτε διαθέσιμο peer. Ταυτόχρονα, κάθε κόμβος SHC μπορεί να τοποθετηθεί στη δική του Ζώνη Διαθεσιμότητας AWS χωρίς κανένα πρόβλημα. Στάδιο 1. Παραμετροποίηση του Target CM (AWS) Σε αυτό το στάδιο, καθιερώνουμε τη συνδεσιμότητα για το cluster IDX multisite. Εντολή αρχικοποίησης Cluster Manager: /opt/splunk/bin/splunk edit cluster-config \-mode manager \-multisite true \-site site1 \-available_sites site1,site2 \-site_replication_factor origin:1,total:2 \-site_search_factor origin:1,total:2 \-replication_factor 2 \-search_factor 2 \-cluster_label idx-aws-smartstore \-secret 'ClusterSecretKey' : server.conf [clustering] mode = manager multisite = true available_sites = site1,site2 cluster_label = idx-aws-smartstore site_replication_factor = origin:1, total:2 site_search_factor = origin:1, total:2 constrain_singlesite_buckets = false Σημειώσεις: available_sites = site1,site2: αναφέρονται μόνο οι τοποθεσίες που φέρουν δεδομένα. Το site0 εξαιρείται σκόπιμα. origin:1,total:2: εγγυάται την αντοχή σε σφάλματα Ζώνης Διαθεσιμότητας - ένα τοπικό αντίγραφο στη ΖΔ όπου δημιουργήθηκε το bucket και ένα δεύτερο αντίγραφο σε άλλη ζώνη. constrain_singlesite_buckets = false: κρίσιμο για το SmartStore και τη μετεγκατάσταση ιστορικών δεδομένων - επιτρέπει την αναπαραγωγή παλαιών buckets χωρίς αυστηρή δέσμευση τοποθεσίας. Target License Manager (LM) Μια ενιαία πηγή αλήθειας, η οποία μπορεί να συνδυαστεί με το CM. Συνιστώ τη μεταφορά τόσο του Target όσο και του Source cluster στο νέο LM. Ο στόχος είναι η αποφυγή Παραβάσεων Αδειοδότησης (License Violations) ενώ τα δύο περιβάλλοντα εκτελούνται παράλληλα. Σημειώστε ότι όλα τα στοιχεία του cluster εκτός από τους indexers - CM, SH, HF και DS - πρέπει να στέλνουν τα εσωτερικά (_internal) και τα αρχεία καταγραφής ελέγχου (_audit) στο target cluster του AWS μέσω . outputs.conf Στάδιο 2. Παραμετροποίηση του Target IDX Αρχικοποιήστε peers σε διαφορετικές ΖΔ, δηλαδή, διαφορετικές τοποθεσίες. Για τον κόμβο στη ΖΔ-Α (site1): /opt/splunk/bin/splunk edit cluster-config -mode peer -manager_uri https://aws-splunk-cm:8089 -multisite true -site site1 -secret 'ClusterSecretKey' Για τον κόμβο στη ΖΔ-Β (site2): /opt/splunk/bin/splunk edit cluster-config -mode peer -manager_uri https://aws-splunk-cm:8089 -multisite true -site site2 -secret 'ClusterSecretKey' : server.conf [imds] imds_version = v2 [cachemanager] eviction_policy = lruk eviction_padding = 102400 Είναι σημαντικό να παραμετροποιηθούν οι εισερχόμενες ροές δεδομένων. Οι νέοι indexers δεν ακούνε σε καμία θύρα από προεπιλογή. Παραμετροποιήστε: 9997 για Splunk-to-Splunk (S2S). 8088 για HEC. Η ανάπτυξη αυτής της παραμετροποίησης εξαρτάται από τον τρόπο διαχείρισης της παραμετροποίησης IDX. Εγκατάσταση του Επιπέδου Ενσωμάτωσης Target HF: πρέπει να μεταφερθούν τα ακόλουθα: Εφαρμογές ($SPLUNK_HOME/etc/apps/). Προγράμματα οδήγησης JDBC. Checkpoints ($SPLUNK_HOME/var/lib/splunk/modinputs). Επαληθεύστε τη δικτυακή συνδεσιμότητα με τις πηγές δεδομένων. Διατηρήστε όλες τις εισαγωγές (inputs) στον Target HF απενεργοποιημένες. Target DS: πρέπει να μεταφερθούν τα ακόλουθα: Deployment Apps ($SPLUNK_HOME/etc/deployment-apps/). Server Classes ($SPLUNK_HOME/etc/system/local/serverclass.conf). Επαληθεύστε τα δικαιώματα και τη συνοχή. Η εναλλαγή στον Target DS θα γίνει αργότερα μέσω DNS. Στάδιο 3. Δημιουργία ενός Υβριδικού SHC Σε αυτό το στάδιο, επεκτείνουμε προσωρινά το Source SHC ώστε να μπορεί να λειτουργεί ταυτόχρονα τόσο με το Source όσο και με το Target IDX cluster. Αυτή η προσέγγιση μας επιτρέπει: αυτόματη συγχρονισμό Αντικειμένων Γνώσης (Knowledge Objects), όπως χειροκίνητες αποθηκευμένες αναζητήσεις, διατήρηση της κατάστασης του KV Store, μεταφορά χρηστών και ειδοποιήσεων χωρίς χρόνο διακοπής. Στρατηγική Υβριδικού SHC: Παραμετροποίηση του Source SHC ώστε να λειτουργεί με δύο CM χρησιμοποιώντας Multi-Cluster Search. Προετοιμασία των νέων κόμβων SH στο AWS ανακτώντας το πακέτο παραμετροποίησης από τον παλιό Deployer. Προσθήκη των νέων κόμβων SH στο υπάρχον SHC και στο κοινό quorum. Μετά τη σταθεροποίηση, μεταφορά της διαχείρισης παραμετροποίησης στον Target Deployer στο AWS. Μετά την ολοκλήρωση της μετεγκατάστασης, αφαίρεση των κόμβων Source SH από το SHC έναν προς έναν. Παραμετροποίηση Multi-Cluster Search στο Source SHC Σε κάθε κόμβο Source SH, επεξεργαστείτε το server.conf και αντικαταστήστε την παλιά ενότητα [clustering] με την ακόλουθη: [clustering] mode = searchhead manager_uri = clustermanager:multi, clustermanager:single [clustermanager:multi] multisite = true site = site0 manager_uri = https://aws-splunk-cm:8089 [clustermanager:single] manager_uri = https://old-splunk-cm:8089 Το site = site0 είναι κρίσιμο για SmartStore + Multisite. Οι κόμβοι SH δεν πρέπει να συμμετέχουν σε site affinity. Κάθε κόμβος SH θα πραγματοποιεί ερωτήματα και στα δύο IDX clusters παράλληλα. Επαληθεύστε ότι το SH μπορεί να δει τους νέους κόμβους IDX στο AWS: index=_internal | dedup splunk_server | table splunk_server Αρχικοποίηση του Target SH Σημαντικό: Κατά την αρχικοποίηση, αναφέρετε τον παλιό URL του Deployer, ώστε οι νέοι κόμβοι SH να ανακτήσουν αμέσως το τρέχον πακέτο εφαρμογών. /opt/splunk/bin/splunk init shcluster-config -mgmt_uri https://aws-splunk-cm:8089 -replication_port 9200 -conf_deploy_fetch_url https://old-splunk-cm:8089 -secret 'OLDClusterSecretKey' Στο , πριν την επανεκκίνηση, καθορίστε την ίδια παραμετροποίηση multi-cluster search που χρησιμοποιείται στους κόμβους Source SH: server.conf [clustering] mode = searchhead manager_uri = clustermanager:multi, clustermanager:single [clustermanager:multi] multisite = true site = site0 manager_uri =https://aws-splunk-cm:8089 [clustermanager:single] manager_uri = https://old-splunk-cm:8089 Εγγραφή σε ένα Ενιαίο SHC Ενταχθείτε στον Target SH στο υπάρχον Source SHC: /opt/splunk/bin/splunk add shcluster-member -current_member_uri https://old-splunk-search:8089 Μηχανισμοί μηδενικού χρόνου διακοπής: τι συμβαίνει στο παρασκήνιο Κατά τη διάρκεια της ενοποίησης του SHC, λειτουργούν παράλληλα πολλοί ανεξάρτητοι μηχανισμοί: Συγχρονισμός Βασικής Παραμετροποίησης: Ο νέος κόμβος SH εγγράφεται στον παλιό Deployer και λαμβάνει το πλήρες πακέτο πριν ενταχθεί στο quorum. Οι κόμβοι Target SH είναι πλήρως συμβατοί με τους κόμβους Source SH. Δυναμική Αναπαραγωγή Αντικειμένων Γνώσης: Ο Captain του Source SHC ξεκινά την online αναπαραγωγή Αντικειμένων Γνώσης. Το Raft παρέχει αυστηρή συνέπεια. Συγχρονισμός Κατάστασης (KV Store): Το SHC επεκτείνει αυτόματα το σύνολο αναπαραγωγής MongoDB. Αυτό είναι ασύγχρονο, αλλά συνεπές. Συνδέσεις Multi-Cluster Search: Όταν ξεκινά μια αναζήτηση, το SH στέλνει την ερώτηση και στα δύο IDX clusters παράλληλα. Η πραγματική πηγή δεδομένων παραμένει διαφανής στους τελικούς χρήστες και την ειδοποίηση. Εναλλαγή Διαχείρισης Παραμετροποίησης (Deployer Switchover) Μετά την επιτυχή ενοποίηση του SHC, η διαχείριση παραμετροποίησης μπορεί να μεταφερθεί πλήρως στον Target Deployer σε όλους τους κόμβους SHC. Επεξεργαστείτε το server.conf σε κάθε SH: [shclustering] conf_deploy_fetch_url = https://aws-splunk-cm:8089 Μετά από αυτό, εκτελέστε μια κυλιόμενη επανεκκίνηση του SHC για να εφαρμόσετε τις ρυθμίσεις. Στάδιο 4. Μετεγκατάσταση Δεδομένων σε S3 (Push to Cloud) Σε αυτό το στάδιο, αρχίζουμε να μεταφέρουμε τα υπάρχοντα warm και cold index buckets από το παλιό cluster indexer στο S3 του AWS, το οποίο στη συνέχεια θα λειτουργεί ως απομακρυσμένο κατάστημα για το Target cluster. Στρατηγική Μετεγκατάστασης Συνιστώ τη μετεγκατάσταση σε στάδια. Ξεκινήστε με ένα μη κρίσιμο index, όπως το test_index. Επαληθεύστε ότι η μεταφόρτωση bucket στο S3 είναι επιτυχής και ότι δεν υπάρχουν σφάλματα. Στη συνέχεια, προσθέστε σταδιακά τα υπόλοιπα index, σε παρτίδες ή όλα μαζί, ανάλογα με τη διέλευση του καναλιού και το φορτίο του συστήματος. στο Source IDX cluster: indexes.conf [volume:remote_store] storageType = remote path = s3://splunk_s3 remote.s3.region = eu-central-1 remote.s3.endpoint = https://s3.eu-central-1.amazonaws.com remote.s3.encryption = sse-s3 remote.s3.supports_versioning = false remote.s3.access_key = XXX remote.s3.secret_key = XXX [test_index] remotePath = volume:remote_store/test_index Τα επιλεγμένα index αρχίζουν να ανεβάζουν τα υπάρχοντα warm και cold buckets στο S3 στο παρασκήνιο. Η διαδικασία είναι ασύγχρονη και δεν διακόπτει την εισαγωγή. Νέα hot buckets συνεχίζουν να γράφονται τοπικά. Επικύρωση Μετεγκατάστασης Ανοίξτε την Κονσόλα AWS στο S3 και επαληθεύστε ότι εμφανίζονται προθέματα με ονόματα όπως τα index. Εναλλακτικά, ελέγξτε τα ενσωματωμένα dashboards στο Monitoring Console -> Indexing -> SmartStore -> Instance. Η Πρόοδος Μετεγκατάστασης (Migration Progress) πρέπει να κινείται προς το 100 τοις εκατό. Η Ουρά Μεταφόρτωσης (Upload Queue) πρέπει να μειώνεται. Οι Αποτυχίες Μεταφόρτωσης/Λήψης (Upload/Download Failures) πρέπει να παραμένουν στο 0. Οποιαδήποτε σφάλματα εδώ συνήθως υποδεικνύουν προβλήματα δικτύου ή δικαιωμάτων IAM. Αναγκαστική μετάβαση (rollover) hot bucket Για να κλείσετε ενεργά αρχεία εγγραφής και να μετατρέψετε όλα τα hot buckets σε warm buckets, ώστε να μπορούν να μεταφορτωθούν στο S3, χρησιμοποιήστε: /opt/splunk/bin/splunk _internal call /data/indexes/*/roll-hot-buckets -auth admin:password Μην προχωρήσετε στο επόμενο στάδιο μέχρι η Ουρά Μεταφόρτωσης (Upload Queue) να φτάσει στο 0. Στάδιο 5. Προσάρτηση του Target IDX Cluster Εφαρμόστε την ακόλουθη παραμετροποίηση στο Target cluster στο indexes.conf: [default] repFactor = auto bucketMerging = true homePath = /splunk_cache/$_index_name/db coldPath = /splunk_cache/$_index_name/colddb thawedPath = /splunk_cache/$_index_name/thaweddb remotePath = volume:remote_store/$_index_name [volume:remote_store] storageType = remote path = s3://splunk_s3 remote.s3.region = eu-central-1 remote.s3.endpoint = https://s3.eu-central-1.amazonaws.com remote.s3.encryption = sse-s3 remote.s3.supports_versioning = false [test_index] Οι Target SmartStore indexers Εισάγουν την παραμετροποίηση, συν