Нуль-перапынковая міграцыя Splunk у inDrive: ад Bare Metal да AWS SmartStore

Прывітанне, я , кіраўнік інжынернага аддзела ў цэнтры аператыўнага кіравання бяспекай inDrive. Іван Саакаў У гэтым артыкуле я дзялюся сваім вопытам і апісваю архітэктуру міграцыі Splunk Enterprise з традыцыйнага лакальнага кластара з лакальнымі дыскамі ў AWS з выкарыстаннем тэхналогіі SmartStore. SmartStore дазваляе выкарыстоўваць S3-сумяшчальнае сховішча для цёплых бакетаў Splunk, захоўваючы пры гэтым магчымасць іх поўнага пошуку. Каб засяродзіць увагу на гэтым артыкуле, я наўмысна апускаю асноўныя этапы ўстаноўкі і налады Splunk Enterprise, замест гэтага канцэнтруючыся на спецыфічных для міграцыі наладах, якія маюць найбольшае значэнне. Ключавое дасягненне выкарыстанага мной падыходу: Нуль часу прастою: Збор даных: Паток даных ніколі не спыняецца. Пошук: Пошук застаецца пастаянна даступным. SOC: Сістэмы апавяшчэння працягваюць працаваць без зніжэння якасці. Карыстальніцкі досвед: Карыстальнікі не заўважаюць пераключэння. Служба падтрымкі Splunk звычайна рэкамендуе спыняць збор даных для такога тыпу міграцыі. Я наўмысна адхіліўся ад гэтай рэкамендацыі. У асяроддзі цэнтра аператыўнага кіравання бяспекай (SOC), які з'яўляецца крытычна важным, спыненне збору даных або апавяшчэнняў проста недапушчальна. 1. Тэрміналогія і архітэктура Вызначэнні і скарачэнні: CM (Cluster Manager): Вузел кіравання для кластара IDX. Compute: Экземпляры Amazon EC2. DS (Deployment Server): Сервер для кіравання канфігурацыямі канцавых кропак. HF (Heavy Forwarder): Выдзелены вузел для збору, аналізу і накіравання даных з пэўных крыніц, такіх як API, базы даных і syslog. IDX (Indexer): Вузел, адказны за індэксаванне і захоўванне даных. Лакальнае сховішча (NVMe): Выкарыстоўваецца строга як кэш, уключаючы гарачыя бакеты і кэшаваныя цёплыя даныя. Не-SmartStore (Крыніца): Першапачатковы лакальны кластар Splunk. Лакальнае сховішча для гарачых, цёплых і халодных даных з класічнай рэплікацыяй. Выдаленае сховішча (S3): Крыніца праўды. Захоўвае ўсе цёплыя бакеты. Забяспечвае незалежнасць ад абсталявання і даўгавечнасць даных праз убудаваную рэплікацыю AWS у розных зонах даступнасці (Multi-AZ). SH (Search Head): Вузел, адказны за пошук і агрэгацыю. SHC (Search Head Cluster): Высокадаступны кластар вузлоў пошуку. SmartStore (Мэта): Мэтавая архітэктура ў AWS. 2. Логіка SmartStore SmartStore змяняе парадыгму захоўвання даных: Выдаленае сховішча (S3): Адзіны ўзровень захоўвання. Незалежна ад каэфіцыента рэплікацыі кластара, у S3 захоўваецца толькі адна унікальная копія кожнага бакета. Гэта забяспечвае значную эканомію выдаткаў на сховішча. Індэктар: Функцыянуе як вузел вылічэнняў, у той час як яго лакальныя дыскі выкарыстоўваюцца выключна як кэш пошуку. Менеджэр кэша, які працуе на вузлах індэктара, адказвае за разумнае кіраванне жыццёвым цыклам даных на хуткіх лакальных NVMe-дысках. Яго паводзіны грунтуюцца на двух механізмах: Выцясненне: Выбарачна ачышчае кэш, калі месца становіцца мала. Алгарытм разумее тыпы файлаў: спачатку выцясняюцца цяжкія даныя, такія як TSIDX-файлы і архівы часопісаў, у той час як лёгкія файлавыя службы, такія як bloom-фільтры, застаюцца на дыску даўжэй, каб пошук быў хуткім. Загрузка (аднаўленне): Падчас пошуку менеджэр кэша не спампоўвае ўвесь бакет з S3. Ён празрыста запампоўвае толькі кампаненты бакета, неабходныя для канкрэтнага запыту, няхай гэта будзе метаданыя, TSIDX або даныя часопіса. Гэта дазваляе выконваць такія каманды, як tstats, без неабходнасці спампоўваць цяжкія зыходныя журналы. Акрамя таго, механізм Lookahead эўрыстычна папярэдне запампоўвае даныя для кампенсацыі затрымкі сеткі. 3. Памер абсталявання (AWS) Для SmartStore крытычна важны баланс паміж прадукцыйнасцю працэсара і лакальнага кэша. Выкарыстанне тамоў EBS у AWS магчыма, але на практыцы гэта звычайна даражэй, калі патрабаванні да IOPS і прапускной здольнасці супастаўныя. Выбар экзэмпляра: сямейства i3en Мэта: i3en.6xlarge (аптымізаваны для захоўвання). Прапускная здольнасць: 150 ГБ/сут/одноранговы, у адпаведнасці з рэкамендацыямі Splunk для такой колькасці ядраў працэсара і аператыўнай памяці. Сховішча: 15 ТБ NVMe Instance Store (RAID 0). Вельмі вялікі кэш дазваляе гарачым даным заставацца лакальнымі, зніжаючы затрымку і выдаткі на запыты да S3. Паколькі S3 ужо ўтрымлівае копію даных, няма неабходнасці люстраваць лакальныя дыскі з дапамогай RAID 1 або 10. Сетка: 25 Гбіт/с. Гэта крытычна важна для хуткага аднаўлення даных з S3 падчас цяжкіх пошукавых запытаў. Важная нюанс: Часовая памяць Дыскі i3en - гэта Instance Store Volumes, фізічна падлучаныя да хоста. Перазагрузка: Даныя захоўваюцца. Спыненне / Завяршэнне: 100 працэнтаў даных на лакальных NVMe-дысках знішчаюцца цалкам і незваротна. Гэта апаратная асаблівасць AWS: калі экзэмпляр EC2 спыняецца, дыскі фізічна адключаюцца і крыптаграфічна ачышчаюцца. Змякчэнне: Уключыць абарону ад завяршэння. Уключыць абарону ад прыпынення (EC2 Console -> Actions -> Instance Settings). 4. Канфігурацыя Amazon S3 (Забяспечэнне вытворчасці) 5. Бяспека і IAM: Гібрыдны доступ Нам быў патрэбны доступ да аднаго S3-бакета як з крынічнага, так і з мэтавага асяроддзя. Наступны набор дазволаў 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-роль (Instance Profile). Ніколі не захоўвайце ключы доступу ў EC2. Валідацыя: sudo -u splunk aws s3 ls s3://splunk-bucket Крыніца: Выкарыстоўваць IAM-карыстальніка. Стварыць сэрвісны карыстальніка. Згенеруйце і . access_key secret_key Укажыце іх у . indexes.conf Пасля завяршэння міграцыі адклікайце ключы. 6. Балансіроўка трафіку (AWS ALB) Карэктная канфігурацыя ALB крытычна важная для стабільнага збору даных праз HTTP Event Collector (HEC) і для вэб-інтэрфейсу. Глабальныя налады слухача Connection Idle Timeout: 290 сек. Для HEC важная налада busyKeepAliveIdleTimeout=300 у секцыі [http] файла inputs.conf. Час чакання ALB павінен быць строга ніжэйшы, каб балансіроўшчык закрываў злучэнне першым. У адваротным выпадку кліент атрымае памылку 502 Bad Gateway. HTTP/2: Уключана. Аднак HTTP/2 таксама павінен быць уключаны на баку кліента для адпраўшчыкаў, якія накіроўваюць трафік да ALB. На практыцы большасць адпраўшчыкаў HEC усё яшчэ выкарыстоўваюць HTTP/1.1. Мэтавыя групы A. HEC (IDX) Праверка здароўя: /services/collector/health правярае, што HEC-эндпоінт актыўны і абслугоўвае запыты на ўзроўні прыкладання, што лепш, чым простая TCP-праверка. Ліпкасць: Уключана (на аснове файлаў cookie), калі useACK=true. Выключана, калі useACK=false. B. Вэб-інтэрфейс (SHC) Ліпкасць: Уключана (на аснове працягласці). Вэб-інтэрфейс з'яўляецца статычным: і сесія карыстальніка, і артыфакты пошукавых задач звязаны з пэўным вузлом SH. Таму ліпкасць павінна быць уключана ў ALB, інакш карыстальнікі будуць пераключацца паміж вузламі SH, сутыкаючыся з памылкамі або неабходнасцю паўторнага ўваходу. 7. Налада інфраструктуры: Мультысайтавы кластар Каб дасягнуць міграцыі з нулявым часам прастою, я выкарыстаў часовую архітэктуру, у якой паралельна працуюць два кластары Splunk, кожны з якіх кіруецца сваім уласным Cluster Manager: Source CM: кіруе існуючым лакальным кластарам. Target CM: кіруе новым мультысайтавым IDX-кластарам у AWS. 8. Архітэктура сайта (Мультысайтавая) У канфігурацыі SmartStore + Multisite крытычна важна правільна прызначаць ролі для сайтаў. Архітэктура: site1: Зона даступнасці AWS A (IDX) site2: Зона даступнасці AWS B (IDX) site0: SHC Чаму Site 0? Калі вы размясціце SH на site1, Splunk аўтаматычна ўключыць Search Affinity, спрабуючы чытаць даныя з лакальных аднарангавых вузлоў. У SmartStore гэта контрпрадуктыўна: лакальны кэш можа быць пустым, у той час як неабходны бакет знаходзіцца ў S3. Прымусовае прытрымліванне сайтаў уплывае на логіку Cache Manager і павялічвае затрымку. Размяшчэнне SHC на site0 адключае гэтыя паводзіны і дазваляе SHC запытваць даныя з любога даступнага аднарангавага вузла. У той жа час кожны вузел SHC можа быць размешчаны ў сваёй уласнай зоне даступнасці AWS без якіх-небудзь праблем. Этап 1. Налада мэтавага CM (AWS) На гэтым этапе мы наладжваем сувязь для мультысайтавага IDX-кластара. Каманда ініцыялізацыі 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: гарантуе адмоўстойлівасць да адмовы ў зоне даступнасці - адна лакальная копія ў ЗД, дзе быў створаны бакет, і другая копія ў іншай зоне. constrain_singlesite_buckets = false: крытычна важна для SmartStore і міграцыі гістарычных даных - дазваляе старым бакетам рэплікавацца без строгага прытрымлівання сайтаў. Мэтавы менеджэр ліцэнзій (LM) Адзіная крыніца праўды, якую можна аб'яднаць з CM. Я рэкамендую перанесці як мэтавы, так і зыходны кластары на новы LM. Мэта - пазбегнуць парушэнняў ліцэнзій, пакуль два асяроддзя працуюць паралельна. Звярніце ўвагу, што ўсе кампаненты кластара, акрамя індэктараў - CM, SH, HF і DS - павінны адпраўляць _internal і _audit журналы ў мэтавы кластар AWS праз . outputs.conf Этап 2. Налада мэтавага IDX Ініцыялізуйце аднарангавыя вузлы ў розных ЗД, гэта значыць, у розных сайтах. Для вузла ў ЗД-А (site1): /opt/splunk/bin/splunk edit cluster-config -mode peer -manager_uri https://aws-splunk-cm:8089 -multisite true -site site1 -secret 'ClusterSecretKey' Для вузла ў ЗД-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 Важна наладзіць уваходныя патокі даных. Новыя індэктары па змаўчанні не слухаюць ніякія парты. Наладзьце: 9997 для Splunk-to-Splunk (S2S). 8088 для HEC. Разгортванне гэтай канфігурацыі залежыць ад таго, як вы кіруеце канфігурацыяй IDX. Налада пласта інтэграцыі Мэтавы HF: неабходна міграваць наступныя элементы: Прыкладанні ($SPLUNK_HOME/etc/apps/). JDBC-драйверы. Чэкапы ($SPLUNK_HOME/var/lib/splunk/modinputs). Праверце сеткавую сувязь з крыніцамі даных. Затрымаеце ўсе ўводы на мэтавым HF адключанымі. Мэтавы DS: неабходна міграваць наступныя элементы: Deployment Apps ($SPLUNK_HOME/etc/deployment-apps/). Server Classes ($SPLUNK_HOME/etc/system/local/serverclass.conf). Праверце дазволы і сумяшчальнасць. Пераключэнне на мэтавы DS будзе зроблена пазней праз DNS. Этап 3. Стварыце гібрыдны SHC На гэтым этапе мы часова пашыраем зыходны SHC, каб ён мог працаваць з абодвума кластарамі IDX (зыходным і мэтавым) адначасова. Гэты падыход дазваляе нам: аўтаматычна сінхранізаваць аб'екты ведаў, такія як захаваныя пошукі, створаныя ўручную, захаваць стан KV Store, забяспечыць пераход карыстальнікаў і сістэмы апавяшчэння без часу прастою. Стратэгія гібрыднага SHC: Наладзьце зыходны SHC для працы з двума CM, выкарыстоўваючы Multi-Cluster Search. Падрыхтуйце новыя SH-вузлы ў AWS, атрымаўшы пакет канфігурацыі са старога Deployer. Дадайце новыя SH-вузлы ў існуючы SHC і агульны кворум. Пасля стабілізацыі перанясіце кіраванне канфігурацыяй на мэтавы Deployer у AWS. Пасля завяршэння міграцыі паступова выдаліце зыходныя SH-вузлы з SHC. Налада Multi-Cluster Search на зыходным SHC На кожным вузле зыходнага 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-вузлы не павінны ўдзельнічаць у прывязцы да сайта. Кожны SH-вузел будзе адначасова запытваць абодва IDX-кластары. Праверце, што SH бачыць новыя IDX-вузлы ў AWS: index=_internal | dedup splunk_server | table splunk_server Ініцыялізацыя мэтавага 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' У , перад перазапускам, укажыце тую ж канфігурацыю мультысайтавага пошуку, што і на зыходных 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 Дадайце мэтавы SH у існуючы зыходны SHC: /opt/splunk/bin/splunk add shcluster-member -current_member_uri https://old-splunk-search:8089 Механізм нулявога часу прастою: што адбываецца пад капотам Падчас кансалідацыі SHC паралельна працуюць некалькі незалежных механізмаў: Сінхранізацыя базавай канфігурацыі: Новы SH-вузел рэгіструецца ў старым Deployer і атрымлівае поўны пакет перад далучэннем да кворуму. Мэтавыя SH-вузлы цалкам сумяшчальныя з зыходнымі SH-вузламі. Дынамічная рэплікацыя аб'ектаў ведаў: Капітан зыходнага SHC ініцыюе анлайнавую рэплікацыю аб'ектаў ведаў. Raft забяспечвае строгую сумяшчальнасць. Сінхранізацыя стану (KV Store): SHC аўтаматычна пашырае рэплікацыйны набор MongoDB. Гэта асінхронна, але сумяшчальна. Злучэнні Multi-Cluster Search: Калі пачынаецца пошук, SH адначасова адпраўляе запыт да абодвух IDX-кластараў. Фактычная крыніца даных застаецца празрыстай для канчатковых карыстальнікаў і сістэмы апавяшчэння. Пераключэнне кіравання канфігурацыяй (Пераключэнне Deployer) Пасля паспяховай сінхранізацыі SHC кіраванне канфігурацыяй можа быць цалкам перанесена на мэтавы Deployer ва ўсіх вузлах SHC. Адрэдагуйце server.conf на кожным SH: [shclustering] conf_deploy_fetch_url = https://aws-splunk-cm:8089 Пасля гэтага выканайце пакрокавую перазагрузку SHC для прымянення налад. Этап 4. Міграцыя даных у S3 (Перанос у воблака) На гэтым этапе мы пачынаем міграцыю існуючых цёплых і халодных індэксных бакетаў са старога індэкснага кластара ў AWS S3, які потым будзе служыць выдаленым сховішчам для мэтавага кластара. Стратэгія міграцыі Я рэкамендую міграваць паэтапна. Пачніце з аднаго некрытычнага індэкса, напрыклад, test_index. Праверце, што загрузка бакетаў у S3 праходзіць паспяхова і без памылак. Затым паступова дадавайце астатнія індэксы, па партыях або ўсё адразу, у залежнасці ад прапускной здольнасці канала і нагрузкі на сістэму. на зыходным IDX-кластары: 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 Выбраныя індэксы пачынаюць загружаць існуючыя цёплыя і халодныя бакеты ў S3 у фонавым рэжыме. Працэс асінхронны і не перапыняе збор даных. Новыя гарачыя бакеты працягваюць запісвацца лакальна. Валідацыя міграцыі Адкрыйце AWS Console у S3 і праверце, што з'явіліся прэфіксы з назвамі індэксаў. Або праверце ўбудаваныя панэлі ў Monitoring Console -> Indexing -> SmartStore -> Instance. Migration Progress павінен набліжацца да 100 працэнтаў. Upload Queue павінен змяншацца. Upload/Download Failures павінны заставацца на 0. Любыя памылкі тут звычайна сведчаць аб праблемах з сеткай або дазволамі IAM. Прымусовае пераключэнне гарачых бакетаў Каб закрыць актыўныя файлы запісу і ператварыць усе гарачыя бакеты ў цёплыя, каб іх можна было загрузіць у S3, выкарыстоўвайце: /opt/splunk/bin/splunk _internal call /data/indexes/*/roll-hot-buckets -auth admin:password Не пераходзьце да наступнага этапу, пакуль Upload Queue не дасягне 0. Этап 5. Падключэнне мэтавага IDX-кластара Прымяніце наступную канфігурацыю да мэтавага кластара ў 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] Мэтавыя SmartStore-індэктары запампоўваюць канфігурацыю, падключаюцца да S3, выяўляюць метаданыя загружаных бакетаў, пачынаюць абслугоўваць пошук па даных у S3 праз Cache Manager і, пасля пераключэння збору даных, пачынаюць запісваць у свае лакальныя гара