
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Hej, jeg er  , Engineering Manager hos inDrive Security Operations Center. Ivan Saakov I denne artikel deler jeg min erfaring og arkitekturen bag migrering af Splunk Enterprise fra en traditionel on-premises bare-metal-klynge med lokale diske til AWS ved hjælp af SmartStore-teknologi. SmartStore muliggør brugen af S3-kompatibel lagring til varme Splunk-buckets, mens de forbliver fuldt søgbare. For at holde denne artikel fokuseret udelader jeg bevidst de grundlæggende Splunk Enterprise-installations- og konfigurationstrin og koncentrerer mig i stedet om de migreringsspecifikke indstillinger, der betyder mest. Nøglepræstation af den tilgang, jeg brugte: Nul nedetid: 
 
 
 
 
 Indtagelse: Datastrømmen stopper aldrig. Søgning: Søgning forbliver løbende tilgængelig. SOC: Alarmering fortsætter med at fungere uden forringelse. Brugeroplevelse: Brugere bemærker ikke omstillingen. Splunk Support anbefaler generelt at stoppe dataindtagelse til denne type migrering. Jeg afveg bevidst fra den vejledning. I et kritisk Security Operations Center (SOC) miljø er det simpelthen uacceptabelt at stoppe indtagelse eller alarmering. 1. Terminologi og arkitektur Definitioner og forkortelser: 
 
 
 
 
 
 
 
 
 
 
 
 CM (Cluster Manager): Manager-noden for IDX-klyngen. Compute: Amazon EC2-forekomster. DS (Deployment Server): En server til styring af slutpunktkonfigurationer HF (Heavy Forwarder): En dedikeret node til indtagelse, parsing og routing af data fra specifikke kilder som API'er, databaser og syslog. IDX (Indexer): En node, der er ansvarlig for indeksering og lagring af data. Lokal lagerplads (NVMe): Bruges strengt som cache, herunder varme buckets og cachelagrede varme data. Ikke-SmartStore (kilde): Den oprindelige bare-metal Splunk-klynge. Lokal lagerplads til varme, varme og kolde data med klassisk replikering. Fjernlager (S3): Kilden til sandheden. Lagrer alle varme buckets. Giver hardwareuafhængighed og dataduration gennem indbygget AWS-replikering på tværs af tilgængelighedszoner (Multi-AZ). SH (Search Head): En node ansvarlig for søgning og aggregering. SHC (Search Head Cluster): En højttilgængelig klynge af søgenoder. SmartStore (mål): Målarkitekturen i AWS. 2. SmartStore-logik SmartStore ændrer lagerparadigmet: 
 
 
 Fjernlager (S3): Et enkelt lagerlag. Uanset klyngens replikationsfaktor gemmes kun én unik kopi af hver bucket i S3. Dette giver massive besparelser på lageromkostninger. Indexer: Fungerer som en compute-node, mens dens lokale diske udelukkende bruges som en søgecache. Cache Manager, som kører på indexer-noderne, er ansvarlig for intelligent styring af datalevetiden på hurtige lokale NVMe-diske. Dens adfærd er baseret på to mekanismer: 
 
 
 Udelukkelse: Rydder selektivt cachen, når pladsen bliver knap. Algoritmen forstår filtyper: tunge data som TSIDX-filer og rå journalarkiver udelukkes først, mens lette servicefiler som bloom-filtre forbliver på disken længere for at holde søgninger hurtige. Hent (Rehydrering): Under en søgning downloader Cache Manager ikke en hel bucket fra S3. Den henter gennemsigtigt kun de buckekomponenter, der er nødvendige for den specifikke forespørgsel, uanset om det er metadata, TSIDX eller journaldata. Dette gør det muligt for kommandoer som tstats at fuldføres uden at downloade tunge rå logs overhovedet. Derudover forudindlæser Lookahead-mekanismen heuristisk data for at kompensere for netværksforsinkelse. 3. Hardware-dimensionering (AWS) For SmartStore er balancen mellem CPU og lokal cache-ydeevne kritisk. Brug af EBS-volumener i AWS er muligt, men i praksis er det normalt dyrere, når IOPS- og gennemløbskravene er sammenlignelige. Instansvalg: i3en-familie 
 
 
 
 
 Mål: i3en.6xlarge (Lageroptimeret). Gennemløb: 150 GB/dag/peer, ifølge Splunk-anbefalinger for dette antal CPU-kerner og RAM. Lagerplads: 15 TB NVMe Instance Store (RAID 0). Den meget store cache giver mulighed for, at varme data forbliver lokale, hvilket minimerer forsinkelsen og reducerer S3-anmodningsomkostninger. Fordi S3 allerede indeholder en kopi af dataene, er der ingen grund til at spejle lokale diske med RAID 1 eller 10. Netværk: 25 Gbps. Dette er kritisk for hurtig genoprettelse fra S3 under tunge søgninger. Vigtig nuance: Flygtig lagerplads 
 
 
 
 i3en-diske er Instance Store-volumener, fysisk tilsluttet værten. Genstart: Data bevares. Stop / Afslut: 100 procent af dataene på de lokale NVMe-diske ødelægges fuldstændigt og uopretteligt. Dette er en hardwarekarakteristik af AWS: når en EC2-instans stoppes, fjernes diskene fysisk og slettes kryptografisk. Afbødning: 
 
 
 Aktivér Termination Protection. Aktivér Stop Protection (EC2-konsol -> Handlinger -> Instansindstillinger). 4. Amazon S3-konfiguration (produktionshærdning) 5. Sikkerhed og IAM: Hybridadgang Vi krævede adgang til en enkelt S3-bucket fra både kilde- og mål-miljøerne. Følgende sæt af S3-tilladelser viste sig at være tilstrækkeligt: {
  "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/*"
    }
  ]
}
 Adgangsimplementering 
 
 
 
 
 
 
 
 
 
 Mål: Brug en IAM-rolle (Instance Profile). Gem aldrig adgangsnøgler på EC2. 
 
 Validering:  sudo -u splunk aws s3 ls s3://splunk-bucket 
 
 Kilde: Brug en IAM-bruger. 
 
 Opret en servicebruger. 
 
 Generér en   og  . access_key secret_key 
 
 Angiv dem i  . indexes.conf 
 
 Efter migreringen er fuldført, tilbagekald nøglerne. 6. Trafikbalancering (AWS ALB) Korrekt ALB-konfiguration er kritisk for stabil indtagelse via HTTP Event Collector (HEC) og for Web UI. Globale lytterindstillinger 
 
 
 
 Connection Idle Timeout: 290 sek. For HEC er den vigtige indstilling busyKeepAliveIdleTimeout=300 i [http]-udsagnet i inputs.conf. ALB-timeouten skal være strengt lavere, så load balanceren lukker forbindelsen først. Ellers modtager klienten en 502 Bad Gateway. HTTP/2: Aktiveret. HTTP/2 skal dog også være aktiveret på klientsiden for afsendere, der sender trafik til ALB'en. I praksis bruger de fleste HEC-afsendere stadig HTTP/1.1. Målgrupper A. HEC (IDX) 
 
 
 Sundhedstjek: /services/collector/health verificerer, at HEC-slutpunktet er live og betjener anmodninger på applikationsniveau, hvilket er bedre end et simpelt TCP-tjek. Klistring: TIL (cookie-baseret) hvis useACK=true. FRA hvis useACK=false. B. Web GUI (SHC) 
 
 
 
 Klistring: TIL (varighedsbaseret). Web UI er stateful: både brugerens session og søgejobartefakter er bundet til en specifik SH-node. Derfor skal klistring være aktiveret i ALB, ellers vil brugerne hoppe mellem SH-noder og opleve fejl eller genlogins. 7. Infrastrukturopsætning: Multisite-klynge For at opnå en migrering med nul nedetid brugte jeg en midlertidig arkitektur, hvor to Splunk-klynger kører parallelt, hver styret af sin egen Cluster Manager: 
 
 
 
 
 Kilde CM: styrer i øjeblikket den eksisterende bare-metal klynge. 
 
 Mål CM: styrer den nye multisite IDX-klynge i AWS. 8. Site-arkitektur (Multisite) I en SmartStore + Multisite-konfiguration er det afgørende at tildele roller til sites korrekt. Arkitektur: 
 
 
 
 site1: AWS Tilgængelighedszone A (IDX) site2: AWS Tilgængelighedszone B (IDX) site0: SHC Hvorfor Site 0? Hvis du placerer SH i site1, aktiverer Splunk automatisk Search Affinity, hvilket forsøger at læse data fra lokale peers. I SmartStore er det kontraproduktivt: den lokale cache kan være tom, mens den krævede bucket ligger i S3. Tvungen site-affinitet forstyrrer Cache Manager-logikken og øger forsinkelsen. Placering af SHC i site0 deaktiverer denne adfærd og giver SHC'en mulighed for at anmode om data fra enhver tilgængelig peer. Samtidig kan hver SHC-node stadig placeres i sin egen AWS Tilgængelighedszone uden problemer. Fase 1. Konfigurer mål-CM (AWS) I dette trin etablerer vi forbindelsen for multisite IDX-klyngen. Initialiseringskommando for 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
 Bemærkninger: 
 
 
 
 available_sites = site1,site2: kun databærende sites er angivet; site0 er bevidst udeladt. origin:1,total:2: garanterer fejltolerance i tilgængelighedszonen - én lokal kopi i den AZ, hvor bucken blev oprettet, og en anden kopi i en anden zone. constrain_singlesite_buckets = false: kritisk for SmartStore og for migrering af historiske data - det tillader gamle buckets at replikere uden streng site-affinitet. Mål Licens Manager (LM) En enkelt kilde til sandhed, som kan kombineres med CM. Jeg anbefaler at flytte både mål- og kildeklyngerne til den nye LM. Målet er at undgå licensafvigelser, mens de to miljøer kører parallelt. Bemærk, at alle klyngekomponenter undtagen indexerne - CM, SH, HF og DS - bør sende _internal og _audit logs til mål-AWS-klyngen via  . outputs.conf Fase 2. Konfigurer mål-IDX Initialiser peers i forskellige AZ'er, dvs. forskellige sites. For noden i 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'
 For noden i 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
 Det er vigtigt at konfigurere indgående datastrømme. Nye indexere lytter ikke på porte som standard. Konfigurer: 
 
 
 9997 for Splunk-til-Splunk (S2S). 8088 for HEC. Implementeringen af denne konfiguration afhænger af, hvordan du administrerer IDX-konfigurationen. Opsætning af integrationslag Mål HF: følgende elementer skal migreres: 
 
 
 
 
 
 Apps ($SPLUNK_HOME/etc/apps/). JDBC-drivere. Kontrolpunkter ($SPLUNK_HOME/var/lib/splunk/modinputs). Bekræft netværksforbindelse til datakilder. Hold alle input på mål-HF deaktiveret. Mål DS: følgende elementer skal migreres: 
 
 
 
 
 Deployment Apps ($SPLUNK_HOME/etc/deployment-apps/). Serverklasser ($SPLUNK_HOME/etc/system/local/serverclass.conf). Bekræft tilladelser og konsistens. Omstilling til mål-DS vil ske senere via DNS. Fase 3. Opbyg en hybrid SHC I dette trin udvider vi midlertidigt kilde-SHC'en, så den kan arbejde med både kilde- og mål-IDX-klyngerne samtidigt. Denne tilgang giver os mulighed for at: 
 
 
 
 automatisk synkronisere Knowledge Objects, såsom manuelt oprettede gemte søgninger, bevare KV Store-tilstanden, overføre brugere og alarmering med nul nedetid. Strategi for hybrid SHC: 
 
 
 
 
 
 Konfigurer kilde-SHC'en til at arbejde med to CM'er ved hjælp af Multi-Cluster Search. Forbered de nye SH-noder i AWS ved at hente konfigurationspakken fra den gamle Deployer. Tilføj de nye SH-noder til den eksisterende SHC og delt quorum. Efter stabilisering, flyt konfigurationsstyring til mål-Deployeren i AWS. Efter migreringen er fuldført, fjernes kilde-SH-noderne fra SHC'en én efter én. Konfigurer Multi-Cluster Search på kilde-SHC På hver kilde SH-node skal du redigere server.conf og erstatte den gamle [clustering]-sektion med følgende: [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 er kritisk for SmartStore + Multisite. SH-noder må ikke deltage i site-affinitet. Hver SH-node vil forespørge begge IDX-klynger parallelt. Bekræft, at SH kan se de nye IDX-noder i AWS: index=_internal | dedup splunk_server | table splunk_server
 Initialiser mål-SH Vigtigt: Under initialisering skal du pege på den gamle Deployer URL, så de nye SH-noder straks henter den aktuelle applikationspakke. /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'
 I  , før genstart, skal du angive den samme multi-cluster søgekonfiguration, som bruges på kilde-SH-noderne: 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
 Tilmeld dig en enkelt SHC Tilmeld mål-SH til den eksisterende kilde-SHC: /opt/splunk/bin/splunk add shcluster-member -current_member_uri 
https://old-splunk-search:8089
 Mekanismer for nul nedetid: hvad der sker bag kulisserne Under SHC-konsolidering opererer flere uafhængige mekanismer parallelt: 
 
 
 
 
 Baseline konfigurationssynkronisering: Den nye SH-node registrerer sig hos den gamle Deployer og modtager hele pakken, før den tilmelder sig quorum. Mål-SH-noderne er fuldt ud kompatible med kilde-SH-noderne. Dynamisk replikering af Knowledge Objects: Kilde-SHC Captain initierer online-replikering af Knowledge Objects. Raft giver streng konsistens. Tilstandssynkronisering (KV Store): SHC udvider automatisk MongoDB-replikationssættet. Dette er asynkront, men konsistent. Multi-Cluster Search-forbindelser: Når en søgning starter, sender SH forespørgslen til begge IDX-klynger parallelt. Den faktiske datakilde forbliver gennemsigtig for slutbrugere og alarmering. Omstilling af konfigurationsstyring (Deployer-omstilling) Efter SHC-synkronisering lykkes, kan konfigurationsstyringen flyttes fuldstændigt til mål-Deployeren på tværs af alle SHC-noder. Rediger server.conf på hver SH: [shclustering]
conf_deploy_fetch_url = https://aws-splunk-cm:8089
 Derefter skal du udføre en rullende genstart af SHC'en for at anvende indstillingerne. Fase 4. Migrer data til S3 (Push til skyen) På dette tidspunkt begynder vi at migrere eksisterende varme og kolde indeks-buckets fra den gamle indexer-klynge til AWS S3, som derefter vil fungere som fjernlager for mål-klyngen. Migreringsstrategi Jeg anbefaler at migrere i etaper. Start med et enkelt ikke-kritisk indeks som test_index. Bekræft, at bucket-upload til S3 lykkes, og at der ikke er fejl. Tilføj derefter gradvist de resterende indekser, i batches eller alle på én gang, afhængigt af kanalens gennemløb og systembelastning.  på kilde-IDX-klyngen: 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
 De valgte indekser begynder at uploade eksisterende varme og kolde buckets til S3 i baggrunden. Processen er asynkron og afbryder ikke indtagelsen. Nye varme buckets fortsætter med at blive skrevet lokalt. Migreringsvalidering 
 
 
 
 
 Åbn AWS Console i S3 og bekræft, at præfikser navngivet efter indekserne vises. Alternativt, tjek de indbyggede dashboards i Monitoring Console -> Indexing -> SmartStore -> Instance. Migration Progress bør bevæge sig mod 100 procent. Upload Queue bør falde. Upload/Download Failures skal forblive på 0. Eventuelle fejl her indikerer normalt netværks- eller IAM-tilladelsesproblemer. Tvungen rollover af varme buckets For at lukke aktive skrivefiler og gøre alle varme buckets til varme buckets, så de kan uploades til S3, skal du bruge: /opt/splunk/bin/splunk _internal call /data/indexes/*/roll-hot-buckets -auth 
admin:password
 Gå ikke videre til næste fase, før Upload Queue når 0. Fase 5. Tilslut mål-IDX-klyngen Anvend følgende konfiguration på mål-klyngen i 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]
 Mål SmartStore indexere indtager konfigurationen, opretter forbindelse til S3, opdager de uploadede bucket-metadata, begynder at servere søgninger over dataene i S3 via Cache Manager, og efter at indtagelsen er skiftet over, begynder de at skrive til deres lokale varme buckets. Skift til mål SmartStore-klynge 
 
 
 DNS- og ALB-skift: Omdiriger al indgående trafik til den nye infrastruktur. Bekræft, at HEC-laget er sundt: curl -k https://aws-splunk-hec.sec/services/collector/health. Aktivér Modulære Input på Mål HF: aktiver inputene og deaktiver dem på Kilde HF. Kontrolpunkterne vil genoptage korrekt, og Splunk vil fortsætte med at indsamle data fra det punkt, hvor det stoppede. Fase 6. Afslut SHC-konfiguration (Oprydning efter migrering) Efter et vellykket skift håndterer mål-IDX-klyngen indtagelse og søgning, og kilde-IDX-klyngen deltager ikke længere i søgningen. Endelig tilstand efter migrering: fjern sektionerne [clustermanager:multi] og [clustermanager:single]. Lad kun en direkte reference til Mål CM være tilbage. : 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
 Fjern Kilde SH-noder fra SHC'en Kør fjernelseskommandoen fra ethvert aktivt SHC-medlem, fortrinsvis Captain, og angiv URI'en for den gamle server, der fjernes, stop derefter den server: /opt/splunk/bin/splunk remove shcluster-member -mgmt_uri https://old-splunk-search:8089
 Efter denne fase: 
 
 
 
 
 SHC er fuldt ud hostet i AWS. Kun Target Cluster Manager er i brug. Multi-cluster search er deaktiveret. Kilde SH-noder er fuldt ud nedlagt. Konklusion Migreringen er fuldført. Kilde-IDX-klyngen bruges effektivt ikke længere. Mål-IDX-klyngen fungerer i produktionsläge, dataene er blevet migreret og ligger nu i AWS S3, og SHC'en er fuldt ud flyttet til AWS. De gamle servere kan deaktiveres permanent. Den centrale betingelse for nul nedetid er opnået: 
 
 
 
 
 
 Indtagelse stoppede aldrig. Søgning og planlagte søgninger forblev tilgængelige. Alarmering og SOC-korrelation blev aldrig afbrudt. KV Store og Knowledge Objects blev migreret uden manuel kopiering. Detektionspipelinen stoppede aldrig. Glad Splunking!

This story contains new, firsthand information uncovered by the writer.

inDrive.Tech

Denne lyd er produceret på historiens originalsprog!

Nulldowntime Splunk-migration hos inDrive: Fra bare metal til AWS SmartStore

About Author

KOMMENTARER

HÆNG TAGS

DENNE ARTIKEL BLEV PRÆsenterET I

Related Stories

Meet Brave: HackerNoon Company of the Week

Yale Media Relations for Entrepreneurs with Journalist Walter Thompson & HackerNoon CEO David Smooke

Meet Sentry: HackerNoon Company of the Week

Avoid These Mistakes to Monetize Internet Products Profitably

Meet Brave: HackerNoon Company of the Week

Yale Media Relations for Entrepreneurs with Journalist Walter Thompson & HackerNoon CEO David Smooke

Meet Sentry: HackerNoon Company of the Week

Avoid These Mistakes to Monetize Internet Products Profitably

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps