הגירת Splunk ללא השבתה ב-inDrive: מ-Bare Metal ל-AWS SmartStore

```html היי, אני , מנהל הנדסה ב-inDrive Security Operations Center. איוון סאאקוב במאמר זה, אני משתף את הניסיון שלי ואת הארכיטקטורה מאחורי העברת Splunk Enterprise מאשכול מקומי מסורתי עם דיסקים מקומיים ל-AWS תוך שימוש בטכנולוגיית SmartStore. SmartStore מאפשר שימוש באחסון תואם S3 עבור דלי Splunk חמים תוך שמירה על יכולת החיפוש המלאה שלהם. כדי לשמור על מיקוד המאמר, אני בכוונה מדלג על שלבי ההתקנה והתצורה הבסיסיים של Splunk Enterprise ומתמקד בהגדרות הספציפיות להעברה שיש להן את החשיבות הרבה ביותר. הישג מרכזי של הגישה שבה השתמשתי: אפס השבתה: קליטה: זרם הנתונים לעולם אינו נעצר. חיפוש: החיפוש נותר זמין באופן רציף. SOC: ההתראות ממשיכות לפעול ללא פגיעה. חווית משתמש: משתמשים אינם מבחינים במעבר. תמיכת Splunk ממליצה בדרך כלל לעצור את קליטת הנתונים עבור סוג העברה זה. אני סטיתי במכוון מההנחיה הזו. בסביבת Security Operations Center (SOC) קריטית, עצירת קליטה או התראות פשוט אינה מקובלת. 1. טרמינולוגיה וארכיטקטורה הגדרות וראשי תיבות: CM (Cluster Manager): צומת הניהול עבור אשכול IDX. Compute: מופעי Amazon EC2. DS (Deployment Server): שרת לניהול תצורות נקודות קצה HF (Heavy Forwarder): צומת ייעודי לקליטה, ניתוח וניתוב נתונים ממקורות ספציפיים כגון APIs, בסיסי נתונים ו-syslog. IDX (Indexer): צומת האחראי על אינדוקס ואחסון נתונים. אחסון מקומי (NVMe): משמש אך ורק כמטמון, כולל דליים חמים ונתונים חמים במטמון. ללא SmartStore (מקור): אשכול ה-Splunk המקומי המקורי. אחסון מקומי לנתונים חמים, חמים וקרים עם שכפול קלאסי. אחסון מרוחק (S3): מקור האמת. מאחסן את כל הדליים החמים. מספק עצמאות חומרה ועמידות נתונים באמצעות שכפול AWS מובנה בין אזורי זמינות (Multi-AZ). SH (Search Head): צומת האחראי על חיפוש וצבירה. SHC (Search Head Cluster): אשכול זמינות גבוהה של צומתי חיפוש. SmartStore (יעד): ארכיטקטורת היעד ב-AWS. 2. לוגיקת SmartStore SmartStore משנה את פרדיגמת האחסון: אחסון מרוחק (S3): שכבת אחסון יחידה. ללא קשר לגורם השכפול של האשכול, רק עותק ייחודי אחד של כל דלי מאוחסן ב-S3. זה מספק חיסכון עצום בעלויות אחסון. Indexer: מתפקד כצומת חישוב, בעוד הדיסקים המקומיים שלו משמשים באופן בלעדי כמטמון חיפוש. מנהל המטמון, שרץ על צומתי ה-indexer, אחראי לניהול מחזור החיים של הנתונים באופן אינטליגנטי על גבי דיסקי NVMe מהירים מקומיים. התנהגותו מבוססת על שני מנגנונים: פינוי: מנקה באופן סלקטיבי את המטמון כאשר השטח הופך נמוך. האלגוריתם מבין סוגי קבצים: קבצי TSIDX וארכיוני יומן גולמיים כבדים מפונים ראשונים, בעוד קבצי שירות קלים כגון bloom filters נשארים בדיסק זמן רב יותר כדי לשמור על חיפושים מהירים. אחזור (Rehydration): במהלך חיפוש, מנהל המטמון אינו מוריד דלי שלם מ-S3. הוא מאחזר באופן שקוף רק את רכיבי הדלי הדרושים לשאילתה הספציפית, בין אם זה מטא-דאטה, TSIDX או נתוני יומן. זה מאפשר לפקודות כמו tstats להשלים מבלי להוריד כלל יומנים גולמיים כבדים. בנוסף, מנגנון Lookahead מאחזר באופן היוריסטי נתונים כדי לפצות על השהיית רשת. 3. גודל חומרה (AWS) עבור SmartStore, האיזון בין ביצועי CPU לביצועי מטמון מקומי הוא קריטי. שימוש בכרכי EBS ב-AWS אפשרי, אך בפועל זה בדרך כלל יקר יותר כאשר דרישות ה-IOPS והתפוקה דומות. בחירת מופע: סדרת i3en יעד: i3en.6xlarge (ממוטב אחסון). תפוקה: 150 GB/יום/עמית, בהתאם להמלצות Splunk למספר זה של ליבות CPU ו-RAM. אחסון: 15 TB NVMe Instance Store (RAID 0). המטמון הגדול מאוד מאפשר לנתונים חמים להישאר מקומיים, ממזער השהיה ומפחית עלויות בקשות S3. מכיוון ש-S3 כבר מכיל עותק של הנתונים, אין צורך לשכפל דיסקים מקומיים עם RAID 1 או 10. רשת: 25 Gbps. זה קריטי לאחזור מהיר מ-S3 במהלך חיפושים כבדים. ניואנס חשוב: אחסון זמני דיסקי i3en הם כרכים מסוג Instance Store, המחוברים פיזית למארח. אתחול מחדש: הנתונים נשמרים. עצירה / סיום: 100 אחוז מהנתונים בדיסקי NVMe המקומיים נהרסים לחלוטין וללא אפשרות שחזור. זוהי תכונה חומרתית של AWS: כאשר מופע EC2 נעצר, הדיסקים מנותקים פיזית ונמחקים באופן קריפטוגרפי. מניעה: הפעל הגנה מפני סיום. הפעל הגנה מפני עצירה (קונסולת EC2 -> פעולות -> הגדרות מופע). 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 Role (פרופיל מופע). לעולם אל תשמור מפתחות גישה על 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) ולממשק המשתמש האינטרנטי. הגדרות מאזין גלובליות Connection Idle Timeout: 290 שניות. עבור HEC, ההגדרה החשובה היא busyKeepAliveIdleTimeout=300 בפסקה [http] של inputs.conf. פסק זמן ה-ALB חייב להיות נמוך יותר באופן מחמיר, כך שמאזן העומסים יסגור את החיבור ראשון. אחרת, הלקוח יקבל 502 Bad Gateway. HTTP/2: מופעל. עם זאת, HTTP/2 חייב להיות מופעל גם בצד הלקוח עבור שולחים הדוחפים תעבורה ל-ALB. בפועל, רוב שולחי HEC עדיין משתמשים ב-HTTP/1.1. קבוצות יעד א. HEC (IDX) בדיקת זמינות: /services/collector/health מוודא שנקודת הקצה של HEC פעילה ומגישה בקשות ברמת היישום, וזה טוב יותר מבדיקת TCP פשוטה. דביקות: מופעל (מבוסס עוגיות) אם useACK=true. כבוי אם useACK=false. ב. ממשק משתמש אינטרנטי (SHC) דביקות: מופעל (מבוסס משך). ממשק המשתמש האינטרנטי הוא Stateful: גם סשן המשתמש וגם ארטיפקטים של משימות חיפוש קשורים לצומת SH ספציפי. לכן, דביקות חייבת להיות מופעלת ב-ALB, אחרת משתמשים יתגלגלו בין צומתי SH וייתקלו בשגיאות או יידרשו להתחבר מחדש. 7. הגדרת תשתית: אשכול רב-אתרי כדי להשיג העברה ללא השבתה, השתמשתי בארכיטקטורה זמנית שבה שני אשכולות Splunk רצים במקביל, כל אחד מנוהל על ידי מנהל האשכול (Cluster Manager) משלו: CM מקור: מנהל כעת את האשכול הקיים על חומרה מקומית. CM יעד: מנהל את אשכול ה-IDX הרב-אתרי החדש ב-AWS. 8. ארכיטקטורת אתרים (רב-אתרי) בתצורת SmartStore + רב-אתרי, קריטי להקצות תפקידים לאתרים בצורה נכונה. ארכיטקטורה: site1: אזור זמינות AWS A (IDX) site2: אזור זמינות AWS B (IDX) site0: SHC מדוע Site 0? אם תמקם את ה-SH ב-site1, Splunk יפעיל אוטומטית Search Affinity, בניסיון לקרוא נתונים מצמתים מקומיים. ב-SmartStore, זה נוגד את התוצאה הרצויה: המטמון המקומי עשוי להיות ריק בעוד הדלי הנדרש נמצא ב-S3. כפיית זיקת אתר מפריעה ללוגיקת מנהל המטמון ומגדילה את ההשהיה. מיקום ה-SHC ב-site0 משבית התנהגות זו ומאפשר ל-SHC לבקש נתונים מכל צומת זמין. יחד עם זאת, כל צומת SHC עדיין יכול להיות ממוקם באזור הזמינות שלו ב-AWS ללא כל בעיה. שלב 1. הגדרת ה-CM היעד (AWS) בשלב זה, אנו יוצרים קישוריות עבור אשכול ה-IDX הרב-אתרי. פקודת אתחול מנהל האשכול: /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: מבטיח עמידות בפני כשל אזור זמינות - עותק מקומי אחד ב-AZ שבו נוצר הדלי ועטק שני באזור אחר. constrain_singlesite_buckets = false: קריטי עבור SmartStore והעברת נתונים היסטוריים - הוא מאפשר לדליים ישנים להשתכפל ללא זיקת אתר קפדנית. מנהל רישיונות יעד (LM) מקור אמת יחיד, שניתן לשלב עם ה-CM. אני ממליץ להעביר את האשכולות היעד והמקור למנהל הרישיונות החדש. המטרה היא למנוע הפרות רישוי בזמן ששתי הסביבות פועלות במקביל. שימו לב שכל רכיבי האשכול למעט ה-indexers - CM, SH, HF, ו-DS - צריכים לשלוח יומני _internal ו- _audit לאשכול ה-AWS היעד דרך . outputs.conf שלב 2. הגדרת ה-IDX היעד אתחל צמתים (peers) באזורי זמינות שונים, כלומר, אתרים שונים. עבור הצומת ב-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' עבור הצומת ב-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 חשוב להגדיר זרמי נתונים נכנסים. Indexers חדשים אינם מאזינים על פורטים כלשהם כברירת מחדל. הגדר: 9997 עבור Splunk-to-Splunk (S2S). 8088 עבור HEC. פריסת תצורה זו תלויה באופן שבו אתה מנהל את תצורת ה-IDX. הגדרת שכבת אינטגרציה HF יעד: יש להעביר את הפריטים הבאים: Apps ($SPLUNK_HOME/etc/apps/). דרייברי JDBC. Checkpoints ($SPLUNK_HOME/var/lib/splunk/modinputs). אמת קישוריות רשת למקורות נתונים. השאר את כל הקלט (inputs) על ה-HF היעד מושבתים. DS יעד: יש להעביר את הפריטים הבאים: Deployment Apps ($SPLUNK_HOME/etc/deployment-apps/). Server Classes ($SPLUNK_HOME/etc/system/local/serverclass.conf). אמת הרשאות ועקביות. המעבר ל-DS היעד יתבצע מאוחר יותר באמצעות DNS. שלב 3. בניית SHC היברידי בשלב זה, אנו מרחיבים זמנית את ה-SHC המקור כדי שיוכל לעבוד עם אשכולות ה-IDX המקורי והיעד בו זמנית. גישה זו מאפשרת לנו: סנכרון אוטומטי של אובייקטי ידע (Knowledge Objects), כגון חיפושים שמורים שנוצרו ידנית, שמירה על מצב ה-KV Store, מעבר משתמשים והתראות ללא השבתה. אסטרטגיית SHC היברידי: הגדר את ה-SHC המקור לעבוד עם שני CMs באמצעות Multi-Cluster Search. הכן את צומתי ה-SH החדשים ב-AWS על ידי אחזור חבילת התצורה מה-Deployer הישן. הוסף את צומתי ה-SH החדשים ל-SHC הקיים ול-quorum המשותף. לאחר ייצוב, העבר את ניהול התצורה ל-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 היעד חשוב: במהלך האתחול, ציין את כתובת ה-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 הישן ומקבל את החבילה המלאה לפני הצטרפות ל-quorum. צומתי ה-SH היעד תואמים לחלוטין לצומתי ה-SH המקוריים. שכפול דינמי של אובייקטי ידע: קפטן ה-SHC המקורי יוזם שכפול מקוון של אובייקטי ידע. Raft מספק עקביות קפדנית. סנכרון מצב (KV Store): ה-SHC מרחיב אוטומטית את קבוצת השכפול של MongoDB. זה אסינכרוני, אך עקבי. חיבורי חיפוש רב-אשכולות: כאשר חיפוש מתחיל, ה-SH שולח את השאילתה לשני אשכולות ה-IDX במקביל. מקור הנתונים בפועל נותר שקוף למשתמשים קצה ולהתראות. מעבר ניהול תצורה (מעבר Deployer) לאחר שסנכרון ה-SHC מצליח, ניתן להעביר באופן מלא את ניהול התצורה ל-Deployer היעד בכל צומתי ה-SHC. ערוך את server.conf בכל SH: [shclustering] conf_deploy_fetch_url = https://aws-splunk-cm:8089 לאחר מכן, בצע הפעלה מחדש של ה-SHC כדי להחיל את ההגדרות. שלב 4. העברת נתונים ל-S3 (דחיפה לענן) בשלב זה, אנו מתחילים להעביר דלי אינדקס חמים וקרים קיימים מאשכול ה-indexer הישן ל-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 ב-S3 ואמת שמופיעים קידומות בשמות האינדקסים. לחלופין, בדוק את לוחות המחוונים המובנים ב-Monitoring Console -> Indexing -> SmartStore -> Instance. התקדמות ההעברה אמורה לנוע לעבר 100 אחוז. תור ההעלאות אמור לרדת. כשלים בהעלאה/הורדה חייבים להישאר על 0. שגיאות כאן בדרך כלל מצביעות על בעיות רשת או הרשאות IAM. הפעל גלישת דליים חמים כדי לסגור קבצי כתיבה פעילים ולהפוך את כל הדליים החמים לדליים חמים כדי שניתן יהיה להעלות אותם ל-S3, השתמש ב: /opt/splunk/bin/splunk _internal call /data/indexes/*/roll-hot-buckets -auth admin:password אל תמשיך לשלב הבא עד שתור ההעלאות יגיע ל-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] ה-indexers של ה-SmartStore היעד קולטים את התצורה, מתחברים ל-S3, מגלים את המטא-דאטה של הדליים שהועלו, מתחילים להגיש חיפוש על הנתונים ב-S3 דרך Cache Manager, ולאחר החלפת הקליטה, מתחילים לכתוב לדליים החמים המקומיים שלהם. מעבר לאשכול ה-SmartStore היעד מתג DNS ו-ALB: הפנה את כל התעבורה הנכנסת לתשתית החדשה. אמת את תקינות שכבת ה-HEC: curl -k https://aws-splunk-hec.sec/services/collector/health. הפעל מודולי קלט (Modular Inputs) על ה-HF היעד: הפעל את הקלט והשבת אותם על ה-HF המקור. ה-checkpoints יתחדשו כראוי, ו-Splunk ימשיך לאסוף נתונים מהנקודה שבה עצר. שלב 6. סיום תצורת SHC (ניקוי לאחר ההעברה) לאחר מעבר מוצלח, אשכול ה-IDX היעד מטפל בקליטה ובחיפוש, ואשכול ה-IDX המקור כבר אינו משתתף בחיפוש. מצב סופי לאחר ההעברה: הסר את הקטעים [clustermanager:multi] ו-[clustermanager:single]. השאר רק הפניה ישירה ל-CM היעד. : 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 הסר צומתי SH מקור מה-SHC הפעל את פ