Migrare Splunk fără întreruperi la inDrive: De la Bare Metal la AWS SmartStore

```html ``` Bună, sunt , Engineering Manager la inDrive Security Operations Center. Ivan Saakov În acest articol, împărtășesc experiența mea și arhitectura din spatele migrării Splunk Enterprise dintr-un cluster tradițional on-premises bare-metal cu discuri locale către AWS, folosind tehnologia SmartStore. SmartStore permite utilizarea stocării compatibile cu S3 pentru ștecheri (buckets) Splunk calzi (warm), menținându-le complet căutabile. Pentru a menține acest articol concentrat, omit intenționat pașii de bază de instalare și configurare Splunk Enterprise și mă concentrez pe setările specifice migrării care contează cel mai mult. Realizare cheie a abordării pe care am folosit-o: Timp de nefuncționare zero: Ingestie: Fluxul de date nu se oprește niciodată. Căutare: Căutarea rămâne continuu disponibilă. SOC: Alertarea continuă să funcționeze fără degradare. Experiența utilizatorului: Utilizatorii nu observă comutarea. Suportul Splunk recomandă, în general, oprirea ingestiei de date pentru acest tip de migrare. Am deviat deliberat de la acea recomandare. Într-un mediu de Security Operations Center (SOC) critic, oprirea ingestiei sau a alertării este pur și simplu inacceptabilă. 1. Terminologie și Arhitectură Definiții și abrevieri: CM (Cluster Manager): Nodul de management pentru clusterul IDX. Compute: Instanțe Amazon EC2. DS (Deployment Server): Un server pentru managementul configurațiilor de endpoint. HF (Heavy Forwarder): Un nod dedicat pentru ingestia, parsarea și rutarea datelor de la surse specifice, cum ar fi API-uri, baze de date și syslog. IDX (Indexer): Un nod responsabil pentru indexarea și stocarea datelor. Stocare locală (NVMe): Folosită strict ca și cache, inclusiv ștecheri calzi (hot buckets) și date calde (warm data) din cache. Non-SmartStore (Sursă): Clusterul Splunk bare-metal original. Stocare locală pentru date calde (hot), calde (warm) și reci (cold) cu replicare clasică. Stocare la distanță (S3): Sursa de adevăr. Stochează toți ștecherii calzi (warm buckets). Oferă independență hardware și durabilitatea datelor prin replicarea nativă AWS între zonele de disponibilitate (Multi-AZ). SH (Search Head): Un nod responsabil pentru căutare și agregare. SHC (Search Head Cluster): Un cluster cu disponibilitate ridicată de noduri de căutare. SmartStore (Țintă): Arhitectura țintă în AWS. 2. Logica SmartStore SmartStore schimbă paradigma stocării: Stocare la distanță (S3): Un singur strat de stocare. Indiferent de Factorul de Replicare al clusterului, doar o singură copie unică a fiecărui ștecher (bucket) este stocată în S3. Acest lucru oferă economii masive la costurile de stocare. Indexer: Funcționează ca un nod de calcul, în timp ce discurile sale locale sunt folosite exclusiv ca și cache de căutare. Cache Manager, care rulează pe nodurile indexer, este responsabil pentru managementul inteligent al ciclului de viață al datelor pe discurile NVMe rapide locale. Comportamentul său se bazează pe două mecanisme: Eviction (Eliminare): Golește selectiv cache-ul atunci când spațiul se reduce. Algoritmul înțelege tipurile de fișiere: fișierele mari precum TSIDX și arhivele jurnal brute sunt eliminate primele, în timp ce fișierele de servicii ușoare, precum filtrele bloom, rămân pe disc mai mult timp pentru a menține căutările rapide. Fetch (Rehidratare): În timpul unei căutări, Cache Manager nu descarcă un întreg ștecher (bucket) de pe S3. Acesta preia transparent doar componentele ștecherului (bucket) necesare interogării specifice, fie că este vorba de metadate, TSIDX sau date jurnal. Acest lucru permite comenzilor precum tstats să se finalizeze fără a descărca deloc logurile brute mari. În plus, mecanismul Lookahead pre-caută euristic date pentru a compensa latența rețelei. 3. Dimensionarea Echipamentelor (AWS) Pentru SmartStore, echilibrul dintre performanța CPU și cache-ul local este critic. Utilizarea volumelor EBS în AWS este posibilă, dar în practică este de obicei mai costisitoare atunci când cerințele IOPS și de throughput sunt comparabile. Alegerea instanței: Familia i3en Țintă: i3en.6xlarge (Optimizat pentru stocare). Throughput: 150 GB/zi/peer, conform recomandărilor Splunk pentru acest număr de nuclee CPU și RAM. Stocare: 15 TB NVMe Instance Store (RAID 0). Cache-ul foarte mare permite datelor calde (hot data) să rămână locale, minimizând latența și reducând costurile de solicitare S3. Deoarece S3 deține deja o copie a datelor, nu este necesară oglindirea discurilor locale cu RAID 1 sau 10. Rețea: 25 Gbps. Acesta este crucial pentru rehidratarea rapidă de pe S3 în timpul căutărilor intensive. Nuanță importantă: Stocare efemeră Discurile i3en sunt volume Instance Store, atașate fizic la gazdă. Repornire: Datele sunt păstrate. Oprire / Terminare: 100% din datele de pe discurile NVMe locale sunt distruse complet și ireversibil. Aceasta este o caracteristică hardware a AWS: atunci când o instanță EC2 este oprită, discurile sunt deconectate fizic și șterse criptografic. Mitigare: Activați Protecția la Terminare. Activați Protecția la Oprire (Consola EC2 -> Acțiuni -> Setări instanță). 4. Configurarea Amazon S3 (Securizare pentru Producție) 5. Securitate și IAM: Acces Hibrid Am necesitat acces la un singur ștecher S3 atât din mediul Sursă, cât și din cel Țintă. Următorul set de permisiuni S3 s-a dovedit suficient: { "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/*" } ] } Implementarea accesului Țintă: Utilizați un Rol IAM (Profil Instanță). Nu stocați niciodată chei de acces pe EC2. Validare: sudo -u splunk aws s3 ls s3://splunk-bucket Sursă: Utilizați un Utilizator IAM. Creați un utilizator de serviciu. Generați o și o . access_key secret_key Specificați-le în . indexes.conf După finalizarea migrării, revocați cheile. 6. Echilibrarea Traficului (AWS ALB) Configurarea corectă a ALB este crucială pentru ingestia stabilă prin HTTP Event Collector (HEC) și pentru interfața Web. Setări Globale Ascultător Connection Idle Timeout: 290 sec. Pentru HEC, setarea importantă este busyKeepAliveIdleTimeout=300 în secțiunea [http] din inputs.conf. Timeout-ul ALB trebuie să fie strict mai mic, astfel încât load balancer-ul să închidă conexiunea mai întâi. Altfel, clientul va primi un 502 Bad Gateway. HTTP/2: Activat. Cu toate acestea, HTTP/2 trebuie să fie activat și pe partea clientului pentru expeditorii care trimit trafic către ALB. În practică, majoritatea expeditorilor HEC folosesc în continuare HTTP/1.1. Grupuri Țintă A. HEC (IDX) Health Check: /services/collector/health verifică dacă endpoint-ul HEC este activ și servește cereri la nivel de aplicație, ceea ce este mai bun decât un simplu test TCP. Stickiness: ON (bazat pe cookie) dacă useACK=true. OFF dacă useACK=false. B. Interfață Web GUI (SHC) Stickiness: ON (bazat pe durată). Interfața Web este stateful: atât sesiunea utilizatorului, cât și artefactele jobului de căutare sunt legate de un nod SH specific. Prin urmare, stickiness trebuie să fie activat în ALB, altfel utilizatorii vor fi mutați între nodurile SH și vor întâmpina erori sau reconectări. 7. Configurarea Infrastructurii: Cluster Multisite Pentru a realiza o migrare cu timp de nefuncționare zero, am folosit o arhitectură temporară în care două clustere Splunk rulează în paralel, fiecare gestionat de propriul său Cluster Manager: CM Sursă: gestionează în prezent clusterul bare-metal existent. CM Țintă: gestionează noul cluster IDX multisite în AWS. 8. Arhitectura Site (Multisite) Într-o configurație SmartStore + Multisite, este crucial să se atribuie corect rolurile site-urilor. Arhitectură: site1: Zonă de Disponibilitate AWS A (IDX) site2: Zonă de Disponibilitate AWS B (IDX) site0: SHC De ce Site 0? Dacă plasați SH în site1, Splunk activează automat Search Affinity, încercând să citească date de la peer-ii locali. În SmartStore, acest lucru este contraproductiv: cache-ul local poate fi gol, în timp ce ștecherul (bucket) necesar se află pe S3. Forțarea afinității de site interferează cu logica Cache Manager și crește latența. Plasarea SHC în site0 dezactivează acest comportament și permite SHC să solicite date de la orice peer disponibil. În același timp, fiecare nod SHC poate fi plasat în propria zonă de disponibilitate AWS fără probleme. Etapa 1. Configurarea CM Țintă (AWS) În această etapă, stabilim conectivitatea pentru clusterul IDX multisite. Comanda de inițializare 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 Note: available_sites = site1,site2: sunt listate doar site-urile care conțin date; site0 este intenționat omis. origin:1,total:2: garantează toleranța la defecte a zonei de disponibilitate - o copie locală în AZ-ul în care a fost creat ștecherul (bucket) și o a doua copie într-o altă zonă. constrain_singlesite_buckets = false: critic pentru SmartStore și pentru migrarea datelor istorice - permite replicarea ștecherilor (bucket) vechi fără afinitate strictă de site. Manager de Licențe Țintă (LM) O singură sursă de adevăr, care poate fi combinată cu CM. Recomand mutarea atât a clusterelor Țintă, cât și a celor Sursă către noul LM. Scopul este de a evita Violările de Licență în timp ce cele două medii rulează în paralel. Rețineți că toate componentele clusterului, cu excepția indexerilor - CM, SH, HF și DS - ar trebui să trimită logurile _internal și _audit către clusterul AWS țintă prin . outputs.conf Etapa 2. Configurarea IDX Țintă Inițializați peer-ii în diferite AZ-uri, adică în site-uri diferite. Pentru nodul din AZ-A (site1): /opt/splunk/bin/splunk edit cluster-config -mode peer -manager_uri https://aws-splunk-cm:8089 -multisite true -site site1 -secret 'ClusterSecretKey' Pentru nodul din AZ-B (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 Este important să configurați fluxurile de date de intrare. Indexerii noi nu ascultă pe niciun port implicit. Configurați: 9997 pentru Splunk-to-Splunk (S2S). 8088 pentru HEC. Implementarea acestei configurații depinde de modul în care gestionați configurația IDX. Configurare strat de integrare HF Țintă: următoarele elemente trebuie migrate: Aplicații ($SPLUNK_HOME/etc/apps/). Drivere JDBC. Checkpoint-uri ($SPLUNK_HOME/var/lib/splunk/modinputs). Verificați conectivitatea de rețea la sursele de date. Păstrați toate input-urile pe HF Țintă dezactivate. DS Țintă: următoarele elemente trebuie migrate: Aplicații de Implementare ($SPLUNK_HOME/etc/deployment-apps/). Clase de servere ($SPLUNK_HOME/etc/system/local/serverclass.conf). Verificați permisiunile și consistența. Comutarea la DS Țintă se va face ulterior prin DNS. Etapa 3. Construirea unui SHC Hibrid În această etapă, extindem temporar SHC Sursă, astfel încât să poată funcționa simultan cu clusterul IDX Sursă și cel Țintă. Această abordare ne permite: Sincronizarea automată a Obiectelor de Cunoștințe (Knowledge Objects), cum ar fi căutările salvate create manual, Păstrarea stării KV Store, Tranziția utilizatorilor și alertarea cu timp de nefuncționare zero. Strategia SHC Hibrid: Configurați SHC Sursă să lucreze cu două CM utilizând Căutare Multi-Cluster. Pregătiți nodurile SH noi în AWS, preluând pachetul de configurare de la vechiul Deployer. Adăugați nodurile SH noi la SHC existent și la quorumul partajat. După stabilizare, mutați managementul configurației la Deployer-ul Țintă în AWS. După finalizarea migrării, eliminați nodurile SH Sursă din SHC, unul câte unul. Configurați Căutarea Multi-Cluster pe SHC Sursă Pe fiecare nod SH Sursă, editați server.conf și înlocuiți secțiunea [clustering] veche cu următoarea: [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 este crucial pentru SmartStore + Multisite. Nodurile SH nu trebuie să participe la afinitatea de site. Fiecare nod SH va interoga ambele clustere IDX în paralel. Verificați dacă SH poate vedea noile noduri IDX din AWS: index=_internal | dedup splunk_server | table splunk_server Inițializați SH Țintă Important: În timpul inițializării, indicați URL-ul vechiului Deployer, astfel încât noile noduri SH să preia imediat pachetul de aplicații curent. /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' În , înainte de repornire, specificați aceeași configurație de căutare multi-cluster utilizată pe nodurile SH Sursă: 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 Alăturați-vă unui singur SHC Alăturați SH Țintă la SHC Sursă existent: /opt/splunk/bin/splunk add shcluster-member -current_member_uri https://old-splunk-search:8089 Mecanisme de timp de nefuncționare zero: ce se întâmplă în culise În timpul consolidării SHC, mai multe mecanisme independente funcționează în paralel: Sincronizare Configurație de Bază: Noul nod SH se înregistrează la vechiul Deployer și primește pachetul complet înainte de a se alătura quorumului. Nodurile SH Țintă sunt complet compatibile cu nodurile SH Sursă. Replicare Dinamică Obiecte de Cunoștințe: Căpitanul SHC Sursă inițiază replicarea online a Obiectelor de Cunoștințe. Raft oferă consistență strictă. Sincronizare Stare (KV Store): SHC extinde automat setul de replicare MongoDB. Acest proces este asincron, dar consistent. Conexiuni Căutare Multi-Cluster: Când începe o căutare, SH trimite interogarea către ambele clustere IDX în paralel. Sursa de date reală rămâne transparentă pentru utilizatorii finali și pentru alertare. Comutare Management Configurație (Comutare Deployer) După ce sincronizarea SHC reușește, managementul configurației poate fi mutat complet la Deployer-ul Țintă pe toate nodurile SHC. Editați server.conf pe fiecare SH: [shclustering] conf_deploy_fetch_url = https://aws-splunk-cm:8089 După aceea, executați o repornire secvențială a SHC pentru a aplica setările. Etapa 4. Migrarea Datelor către S3 (Push către Cloud) În această etapă, începem migrarea ștecherilor (bucket) calzi și reci existenți de la clusterul indexer vechi către S3-ul AWS, care va servi apoi ca și stocare la distanță pentru clusterul Țintă. Strategia de migrare Recomand migrarea în etape. Începeți cu un index necritic, cum ar fi test_index. Verificați dacă încărcarea ștecherilor (bucket) pe S3 reușește și dacă nu există erori. Apoi, adăugați treptat indexurile rămase, în loturi sau toate odată, în funcție de throughput-ul canalului și sarcina sistemului. pe clusterul IDX Sursă: 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 Indexurile selectate încep să încarce ștecherii (bucket) calzi și reci existenți pe S3 în fundal. Procesul este asincron și nu întrerupe ingestia. Noii ștecheri calzi (hot buckets) continuă să fie scriși local. Validarea migrării Deschideți consola AWS în S3 și verificați dacă apar prefixe denumite după indexuri. Alternativ, verificați dashboard-urile integrate în Monitoring Console -> Indexing -> SmartStore -> Instance. Progress-ul migrării ar trebui să se apropie de 100%. Upload Queue (Coada de încărcare) ar trebui să scadă. Upload/Download Failures (Eșecuri de încărcare/descărcare) trebuie să rămână la 0. Orice eroare aici indică de obicei probleme de rețea sau de permisiuni IAM. Forțați rollover-ul ștecherilor calzi (hot bucket) Pentru a închide fișierele active de scriere și a transforma toți ștecherii calzi (hot buckets) în ștecheri calzi (warm buckets), astfel încât aceștia să poată fi încărcați pe S3, utilizați: /opt/splunk/bin/splunk _internal call /data/indexes/*/roll-hot-buckets -auth admin:password Nu treceți la etapa următoare până când Upload Queue nu ajunge la 0. Etapa 5. Atașarea Clusterului IDX Țintă Aplicați următoarea configurație pe clusterul Țintă în 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] Indexatorii SmartStore Țintă ingestionează configurația, se conectează la S3, descoperă metadatele ștecherilor (bucket) încărcate, încep să servească căutarea pe datele din S3 prin Cache Manager și, după ce ingestia este comutată, încep să scrie în ștecherii lor locali calzi (hot buckets). Comutare către Clusterul SmartStore Țintă Comutare DNS și ALB: Redirecționați tot traficul de intrare către noua infrastructură. Verificați dacă stratul HEC este sănătos: curl -k https://aws-splunk-hec.sec/services/collector/health. Activați Input-urile Modulare pe HF Țintă: activați input-urile și dezactivați-le pe HF Sursă. Checkpoint-urile vor relua corect, iar Splunk va continua să colecteze date din punctul în care s-a oprit. Etapa 6. Finalizarea Configurației SHC (Curățare Post-Migrare) După o comutare reușită, clusterul IDX Țintă gestionează ingestia și căutarea, iar clusterul IDX Sursă nu mai participă la căutare. Stare Finală Post-Migrare: eliminați secțiunile [clustermanager:multi] și [clustermanager:single]. Lăsați doar o referință directă la CM Țintă. : server.conf [general] site = site0 serverName = aws-splunk-search [license] manager_uri = https://aws-splunk-cm:8089 [replication_port://9200] [shclustering] conf_deploy_fetch_url = https://aws-splunk-cm:8089 mgmt_uri = https://aws-splunk-search:8089 replication_factor = 3 shcluster_label = shc_aws_prod [clustering] mode = searchhead multisite = true manager_uri = https://aws-splunk-cm:8089 Eliminați nodurile SH Sursă din SHC Rulați comanda de eliminare de la orice membru SHC activ, de preferință Căpitanul, specificând URI-ul serverului vechi care urmează să fie eliminat, apoi opriți acel server: /opt/splunk/bin/splunk remove shcluster-member -mgmt_uri https://old-splunk-search:8089 După această etapă: SHC este complet găzduit în AWS. Se utilizează doar Cluster Manager-ul Țintă. Căutarea multi-cluster este dezactivată. Nodurile SH Sursă sunt complet scoase din uz. Concluzie Migrarea este finalizată. Clusterul IDX Sursă nu mai este efectiv utilizat. Clusterul IDX Țintă funcționează în modul de producție, datele au fost migrate și acum rezidă pe S3-ul AWS, iar SHC a fost mutat complet în AWS. Serverele vechi pot fi scoase din uz permanent. Condiția cheie de timp de nefuncționare zero a fost atinsă: Ingestia nu s-a oprit niciodată. Căutarea și căutările programate au rămas disponibile. Alertarea și corelarea SOC nu au fost întrerupte niciodată. KV Store și Obiectele de Cunoștințe au fost migrate fără copiere manuală. Pipeline-ul de detecție nu s-a oprit niciodată. Happy Splunking!