Nul-downtime Splunk-migratie bij inDrive: Van bare metal naar AWS SmartStore

Hoi, ik ben , Engineering Manager bij het inDrive Security Operations Center. Ivan Saakov In dit artikel deel ik mijn ervaring en de architectuur achter de migratie van Splunk Enterprise van een traditioneel on-premises bare-metal cluster met lokale schijven naar AWS met behulp van SmartStore-technologie. SmartStore maakt gebruik van S3-compatibele opslag voor warme Splunk-buckets, terwijl deze volledig doorzoekbaar blijven. Om dit artikel gefocust te houden, laat ik de basale Splunk Enterprise-installatie- en configuratiestappen bewust weg en concentreer ik me op de migratiespecifieke instellingen die het belangrijkst zijn. Belangrijkste prestatie van de door mij gebruikte aanpak: Nul Downtime: Ingestie: De datastroom stopt nooit. Zoeken: Zoeken blijft continu beschikbaar. SOC: Alerting blijft zonder degradatie werken. Gebruikerservaring: Gebruikers merken de overgang niet op. Splunk Support raadt over het algemeen aan om de gegevensinvoer te stoppen voor dit type migratie. Ik week bewust af van dat advies. In een missiekritische Security Operations Center (SOC)-omgeving is het stoppen van ingestie of alerting simpelweg onacceptabel. 1. Terminologie en Architectuur Definities en afkortingen: CM (Cluster Manager): Het managerknooppunt voor het IDX-cluster. Compute: Amazon EC2-instanties. DS (Deployment Server): Een server voor het beheren van endpointconfiguraties HF (Heavy Forwarder): Een speciaal knooppunt voor het inhalen, parsen en routeren van gegevens van specifieke bronnen zoals API's, databases en syslog. IDX (Indexer): Een knooppunt dat verantwoordelijk is voor het indexeren en opslaan van gegevens. Lokale opslag (NVMe): Strikt gebruikt als cache, inclusief hete buckets en gecachte warme gegevens. Niet-SmartStore (Bron): Het originele bare-metal Splunk-cluster. Lokale opslag voor hete, warme en koude gegevens met klassieke replicatie. Externe Opslag (S3): De bron van waarheid. Slaat alle warme buckets op. Biedt hardware-onafhankelijkheid en gegevensduurzaamheid door native AWS-replicatie over Beschikbaarheidszones (Multi-AZ). SH (Search Head): Een knooppunt dat verantwoordelijk is voor zoeken en aggregeren. SHC (Search Head Cluster): Een zeer beschikbare cluster van zoekknooppunten. SmartStore (Doel): De doelarchitectuur in AWS. 2. SmartStore Logica SmartStore verandert het opslagparadigma: Externe Opslag (S3): Een enkele opslaglaag. Ongeacht de Cluster Replicatiefactor, wordt slechts één unieke kopie van elke bucket opgeslagen in S3. Dit levert enorme besparingen op opslagkosten op. Indexer: Functioneert als een rekenknooppunt, terwijl de lokale schijven uitsluitend als zoekcache worden gebruikt. De Cache Manager, die op de indexerknooppunten draait, is verantwoordelijk voor het intelligent beheren van de levenscyclus van gegevens op snelle lokale NVMe-schijven. Het gedrag is gebaseerd op twee mechanismen: Verwijdering: Maakt selectief de cache leeg wanneer de ruimte krap wordt. Het algoritme begrijpt bestandstypen: zware gegevens zoals TSIDX-bestanden en ruwe journalarchieven worden eerst verwijderd, terwijl lichtgewicht servicebestanden zoals bloomfilters langer op schijf blijven om zoekopdrachten snel te houden. Ophalen (Herhydratatie): Tijdens een zoekopdracht downloadt de Cache Manager niet een hele bucket van S3. Het haalt transparant alleen de bucketcomponenten op die nodig zijn voor de specifieke query, of het nu metadata, TSIDX of journalgegevens zijn. Hierdoor kunnen commando's zoals tstats worden voltooid zonder zware ruwe logs te downloaden. Bovendien prefetchet het Lookahead-mechanisme heuristisch gegevens om netwerklatentie te compenseren. 3. Hardwareafmetingen (AWS) Voor SmartStore is de balans tussen CPU en lokale cacheprestaties cruciaal. Het gebruik van EBS-volumes in AWS is mogelijk, maar in de praktijk is het meestal duurder wanneer de IOPS- en doorvoereisen vergelijkbaar zijn. Instancekeuze: i3en-familie Doel: i3en.6xlarge (Storage Optimized). Doorvoer: 150 GB/dag/peer, volgens Splunk-aanbevelingen voor dit aantal CPU-kernen en RAM. Opslag: 15 TB NVMe Instance Store (RAID 0). De zeer grote cache zorgt ervoor dat hete gegevens lokaal blijven, wat de latentie minimaliseert en de kosten van S3-verzoeken verlaagt. Omdat S3 al een kopie van de gegevens bevat, is het niet nodig om lokale schijven te spiegelen met RAID 1 of 10. Netwerk: 25 Gbps. Dit is cruciaal voor snelle herhydratatie vanuit S3 tijdens zware zoekopdrachten. Belangrijke nuance: Ephemere opslag i3en-schijven zijn Instance Store-volumes, fysiek verbonden met de host. Herstart: Gegevens blijven behouden. Stop / Beëindig: 100 procent van de gegevens op de lokale NVMe-schijven wordt volledig en onherroepelijk vernietigd. Dit is een hardwarekenmerk van AWS: wanneer een EC2-instantie wordt gestopt, worden de schijven fysiek losgekoppeld en cryptografisch gewist. Mitigatie: Schakel Beëindigingsbescherming in. Schakel Stopbescherming in (EC2 Console -> Acties -> Instantie-instellingen). 4. Amazon S3-configuratie (Productie Hardening) 5. Beveiliging en IAM: Hybride Toegang We hadden toegang nodig tot één S3-bucket vanuit zowel de Bron- als de Doelomgeving. De volgende set S3-machtigingen bleek voldoende: { "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/*" } ] } Toegangsimplementatie Doel: Gebruik een IAM-rol (Instantieprofiel). Sla nooit toegangssleutels op EC2 op. Validatie: sudo -u splunk aws s3 ls s3://splunk-bucket Bron: Gebruik een IAM-gebruiker. Maak een servicegebruiker aan. Genereer een en . access_key secret_key Specificeer deze in . indexes.conf Nadat de migratie is voltooid, trekt u de sleutels in. 6. Verkeersbalancering (AWS ALB) Een juiste ALB-configuratie is cruciaal voor stabiele ingestie via HTTP Event Collector (HEC) en voor de webinterface. Globale Luisteraarinstellingen Connection Idle Timeout: 290 sec. Voor HEC is de belangrijke instelling busyKeepAliveIdleTimeout=300 in de [http]-stanza van inputs.conf. De ALB-timeout moet strikt lager zijn, zodat de load balancer de verbinding eerst sluit. Anders ontvangt de client een 502 Bad Gateway. HTTP/2: Ingeschakeld. HTTP/2 moet echter ook aan de clientzijde worden ingeschakeld voor afzenders die verkeer naar de ALB pushen. In de praktijk gebruiken de meeste HEC-afzenders nog steeds HTTP/1.1. Doelgroepen A. HEC (IDX) Health Check: /services/collector/health verifieert dat het HEC-eindpunt leeft en verzoeken op applicatieniveau bedient, wat beter is dan een eenvoudige TCP-check. Plakkerigheid: AAN (op cookie gebaseerd) als useACK=true. UIT als useACK=false. B. Web GUI (SHC) Plakkerigheid: AAN (op duur gebaseerd). De webinterface is stateful: zowel de gebruikerssessie als de zoektaakartefacten zijn gebonden aan een specifiek SH-knooppunt. Daarom moet plakkerigheid in ALB zijn ingeschakeld, anders zullen gebruikers tussen SH-knooppunten stuiteren en fouten of opnieuw inloggen ervaren. 7. Infrastructuurinstelling: Multisite Cluster Om een migratie met nul downtime te bereiken, heb ik een tijdelijke architectuur gebruikt waarin twee Splunk-clusters parallel draaien, elk beheerd door zijn eigen Cluster Manager: Bron CM: beheert momenteel het bestaande bare-metal cluster. Doel CM: beheert het nieuwe multisite IDX-cluster in AWS. 8. Site Architectuur (Multisite) In een SmartStore + Multisite-configuratie is het cruciaal om rollen correct aan sites toe te wijzen. Architectuur: site1: AWS Beschikbaarheidszone A (IDX) site2: AWS Beschikbaarheidszone B (IDX) site0: SHC Waarom Site 0? Als u SH in site1 plaatst, schakelt Splunk automatisch Search Affinity in, waarbij wordt geprobeerd gegevens van lokale peers te lezen. In SmartStore is dat contraproductief: de lokale cache kan leeg zijn terwijl de vereiste bucket zich in S3 bevindt. Het forceren van site-affiniteit interfereert met de logica van de Cache Manager en verhoogt de latentie. Het plaatsen van de SHC in site0 schakelt dat gedrag uit en stelt de SHC in staat gegevens van elke beschikbare peer op te vragen. Tegelijkertijd kan elk SHC-knooppunt nog steeds in zijn eigen AWS-beschikbaarheidszone worden geplaatst zonder problemen. Fase 1. Configureer de Doel-CM (AWS) In deze fase leggen we de verbinding voor het multisite IDX-cluster. Cluster Manager initialisatiecommando: /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 Notities: available_sites = site1,site2: alleen gegevensdragende sites worden vermeld; site0 is opzettelijk uitgesloten. origin:1,total:2: garandeert beschikbaarheidszone-fouttolerantie - één lokale kopie in de AZ waar de bucket is gemaakt en een tweede kopie in een andere zone. constrain_singlesite_buckets = false: cruciaal voor SmartStore en voor migratie van historische gegevens - het staat oude buckets toe te repliceren zonder strikte site-affiniteit. Doel Licentiemanager (LM) Eén bron van waarheid, die kan worden gecombineerd met de CM. Ik raad aan om zowel de doel- als de bronclusters naar de nieuwe LM te verplaatsen. Het doel is om Licentieovertredingen te voorkomen terwijl de twee omgevingen parallel draaien. Merk op dat alle clustercomponenten, behalve de indexers - CM, SH, HF en DS - _internal en _audit logs naar het doel AWS-cluster moeten sturen via . outputs.conf Fase 2. Configureer de Doel-IDX Initialiseer peers in verschillende AZ's, dat wil zeggen, verschillende sites. Voor het knooppunt in 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' Voor het knooppunt in 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 Het is belangrijk om binnenkomende datastromen te configureren. Nieuwe indexers luisteren standaard niet op poorten. Configureer: 9997 voor Splunk-naar-Splunk (S2S). 8088 voor HEC. De implementatie van deze configuratie hangt af van hoe u de IDX-configuratie beheert. Opzet Integratielaag Doel HF: de volgende items moeten worden gemigreerd: Apps ($SPLUNK_HOME/etc/apps/). JDBC-stuurprogramma's. Checkpoints ($SPLUNK_HOME/var/lib/splunk/modinputs). Verifieer netwerkconnectiviteit met gegevensbronnen. Houd alle inputs op de doel-HF uitgeschakeld. Doel DS: de volgende items moeten worden gemigreerd: Deployment Apps ($SPLUNK_HOME/etc/deployment-apps/). Server Classes ($SPLUNK_HOME/etc/system/local/serverclass.conf). Verifieer machtigingen en consistentie. De overschakeling naar de doel-DS zal later via DNS gebeuren. Fase 3. Bouw een Hybride SHC In deze fase breiden we tijdelijk de Bron SHC uit, zodat deze tegelijkertijd met zowel de Bron- als de Doel-IDX-clusters kan werken. Deze aanpak stelt ons in staat om: Kennisobjecten, zoals handmatig gemaakte opgeslagen zoekopdrachten, automatisch synchroniseren. De KV Store-status behouden. Gebruikers en alerting overzetten met nul downtime. Hybride SHC-strategie: Configureer de Bron SHC om te werken met twee CM's door Multi-Cluster Search te gebruiken. Bereid de nieuwe SH-knooppunten in AWS voor door de configuratiebundel op te halen van de oude Deployer. Voeg de nieuwe SH-knooppunten toe aan de bestaande SHC en gedeelde quorum. Verplaats na stabilisatie het configuratiebeheer naar de Doel Deployer in AWS. Verwijder na voltooiing van de migratie één voor één de Bron SH-knooppunten uit de SHC. Configureer Multi-Cluster Search op de Bron SHC Bewerk op elk Bron SH-knooppunt server.conf en vervang het oude [clustering]-gedeelte door het volgende: [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 is cruciaal voor SmartStore + Multisite. SH-knooppunten mogen niet deelnemen aan site-affiniteit. Elk SH-knooppunt zal beide IDX-clusters parallel bevragen. Verifieer dat de SH de nieuwe IDX-knooppunten in AWS kan zien: index=_internal | dedup splunk_server | table splunk_server Initialiseer de Doel SH Belangrijk: Wijs tijdens de initialisatie naar de oude Deployer URL, zodat de nieuwe SH-knooppunten onmiddellijk de huidige applicatiebundel ophalen. /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' Specificeer in , vóór de herstart, dezelfde multi-cluster zoekconfiguratie die op de Bron SH-knooppunten wordt gebruikt: 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 Voeg toe aan een enkele SHC Voeg het doel SH toe aan de bestaande Bron SHC: /opt/splunk/bin/splunk add shcluster-member -current_member_uri https://old-splunk-search:8089 Mechanismen voor nul downtime: wat er achter de schermen gebeurt Tijdens SHC-consolidatie werken verschillende onafhankelijke mechanismen parallel: Basisconfiguratie Synchronisatie: Het nieuwe SH-knooppunt registreert zich bij de oude Deployer en ontvangt de volledige bundel voordat het deelneemt aan het quorum. De Doel SH-knooppunten zijn volledig compatibel met de Bron SH-knooppunten. Dynamische Kennisobject Replicatie: De Bron SHC Captain initieert online replicatie van Kennisobjecten. Raft biedt strikte consistentie. Status synchronisatie (KV Store): De SHC breidt automatisch de MongoDB replica set uit. Dit is asynchroon, maar consistent. Multi-Cluster Zoekverbindingen: Wanneer een zoekopdracht start, stuurt de SH de query parallel naar beide IDX-clusters. De daadwerkelijke gegevensbron blijft transparant voor eindgebruikers en alerting. Overschakeling Configuratiebeheer (Deployer Overschakeling) Nadat de SHC-synchronisatie succesvol is, kan het configuratiebeheer volledig worden overgezet naar de Doel Deployer op alle SHC-knooppunten. Bewerk server.conf op elke SH: [shclustering] conf_deploy_fetch_url = https://aws-splunk-cm:8089 Voer daarna een rollende herstart van de SHC uit om de instellingen toe te passen. Fase 4. Migreer Gegevens naar S3 (Push naar Cloud) In deze fase beginnen we met het migreren van bestaande warme en koude index-buckets van het oude indexer-cluster naar AWS S3, dat vervolgens zal dienen als de externe opslag voor het Doelcluster. Migratiestrategie Ik raad aan om in fasen te migreren. Begin met één niet-kritieke index zoals test_index. Verifieer dat het uploaden van buckets naar S3 slaagt en dat er geen fouten zijn. Voeg vervolgens geleidelijk de resterende indexen toe, in batches of allemaal tegelijk, afhankelijk van de kanaaldoorvoer en de systeembelasting. op het Bron 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 De geselecteerde indexen beginnen met het uploaden van bestaande warme en koude buckets naar S3 op de achtergrond. Het proces is asynchroon en onderbreekt de ingestie niet. Nieuwe hete buckets blijven lokaal worden geschreven. Migratievalidatie Open de AWS Console in S3 en verifieer dat er prefixes verschijnen met de namen van de indexen. Controleer ook de ingebouwde dashboards in Monitoring Console -> Indexing -> SmartStore -> Instance. Migration Progress zou naar 100 procent moeten gaan. Upload Queue zou moeten afnemen. Upload/Download Failures moeten op 0 blijven. Fouten hier duiden meestal op netwerk- of IAM-permissieproblemen. Forceer hete bucket rollover Om actieve schrijfbestanden te sluiten en alle hete buckets om te zetten in warme buckets, zodat ze naar S3 kunnen worden geüpload, gebruikt u: /opt/splunk/bin/splunk _internal call /data/indexes/*/roll-hot-buckets -auth admin:password Ga niet verder naar de volgende fase totdat de Upload Queue 0 bereikt. Fase 5. Koppel het Doel-IDX-cluster Pas de volgende configuratie toe op het Doelcluster in 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] De Doel SmartStore indexers nemen de configuratie in, maken verbinding met S3, ontdekken de geüploade bucketmetadata, beginnen met het serveren van zoekopdrachten over de gegevens in S3 via de Cache Manager, en beginnen na het overschakelen van ingestie met schrijven naar hun lokale hete buckets. Overschakelen naar het Doel SmartStore Cluster DNS en ALB overschakeling: Omleiden van al het inkomende verkeer naar de nieuwe infrastructuur. Verifieer dat de HEC-laag gezond is: curl -k https://aws-splunk-hec.sec/services/collector/health. Activeer Modulaire Inputs op de Doel HF: schakel de inputs in en schakel ze uit op de Bron HF. De checkpoints zullen correct hervatten en Splunk zal doorgaan met het verzamelen van gegevens vanaf het punt waar het gestopt is. Fase 6. Finaliseer SHC-configuratie (Post-migratie opruiming) Na een succesvolle overschakeling beheert het Doel IDX-cluster de ingestie en zoekopdrachten, en het Bron IDX-cluster neemt niet langer deel aan zoekopdrachten. Finale staat na migratie: verwijder de [clustermanager:multi] en [clustermanager:single] secties. Laat alleen een directe verwijzing naar de Doel CM over. : 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 Verwijder Bron SH-knooppunten uit de SHC Voer het verwijderingscommando uit vanaf een actief SHC-lid, bij voorkeur de Captain, waarbij u de URI van de oude te verwijderen server specificeert, en stop vervolgens die server: /opt/splunk/bin/splunk remove shcluster-member -mgmt_uri https://old-splunk-search:8089 Na deze fase: De SHC is volledig gehost in AWS. Alleen de Doel Cluster Manager wordt gebruikt. Multi-cluster zoeken is uitgeschakeld. De Bron SH-knooppunten zijn volledig gedeactiveerd. Conclusie De migratie is voltooid. Het Bron IDX-cluster wordt effectief niet meer gebruikt. Het Doel IDX-cluster functioneert in productiemodus, de gegevens zijn gemigreerd en bevinden zich nu in AWS S3, en de SHC is volledig naar AWS verplaatst. De oude servers kunnen permanent worden gedeactiveerd. De belangrijkste voorwaarde van nul downtime is bereikt: Ingestie is nooit gestopt. Zoeken en geplande zoekopdrachten bleven beschikbaar. Alerting en SOC-correlatie werden nooit onderbroken. KV Store en Kennisobjecten werden gemigreerd zonder handmatige kopieeracties. De detectiepijplijn is nooit gestopt. Happy Splunking!