תצורת נתב mongos של MongoDB עבור אשכולות ייצור

יישומים מאבדים חיבור למקבץ MongoDB מבוסס-שרדינג. הסיבה היא לעיתים קרובות mongos לא מוגדר כראוי: נקודת כשל יחידה, מאגר חיבורים מנוצל, או מטמון מטא-דאטה מיושן. במאמר זה, אנו מראים כיצד להגדיר mongos מאפס עבור עומסי ייצור, ולהימנע מהמלכודות הללו. אופטימיזציה של mongos בפרויקט אחד הפחיתה את זמן האחזור ב-30% וחסכה 10,000 דולר בשנה בעלויות תשתית. לקוח אחד דיווח על חיסכון של למעלה מ-12,000 דולר בשנה לאחר יישום ההמלצות שלנו.

mongos הוא נקודת הכניסה היחידה עבור יישומים למקבץ מבוסס-שרדינג. הוא פועל כנתב שרדינג, מקבל שאילתות, קובע לאילו שרדים לנתב אותן, ומאחד תוצאות. הוא אינו מאחסן נתונים — רק מטא-דאטה בזיכרון משרתי התצורה בעת האתחול.

אילו בעיות אנו פותרים

מיצוי מאגר חיבורים. mongos פותח חיבורים לכל שרד עבור כל חיבור לקוח. עם 100 חיבורי לקוח ו-5 שרדים, הוא מחזיק עד 500 חיבורים לשרדים. אם maxIncomingConnections נמוך מדי, לקוחות חדשים לא יכולים להתחבר. בניסיוננו בפרויקט עם 50 אלף פעולות בשנייה, זה גרם לזמן-קצוב — הגדלת הפרמטר מ-2000 ל-5000 ואופטימיזציה של מאגר החיבורים בצד היישום פתרו את הבעיה תוך שעה. עם 10 שרדים ו-2000 לקוחות, mongos יכול להחזיק עד 20,000 חיבורים לשרדים, אז תכננו עם מרווח ביטחון. הגדרה נכונה של מאגר החיבורים מנעה השבתה משמעותית.

StaleShardVersion. לאחר העברת צ'אנק או resharding, מטמון המטא-דאטה על mongos יכול להתייתר. סימפטום: שאילתה הולכת לשרד הלא נכון, מחזירה StaleShardVersion, ו-mongos מנסה שוב. שקוף ליישום, אבל במהלך resharding המוני מספר הניסיונות החוזרים גדל באופן ניכר. בפרויקט אחד, ניסיונות חוזרים הגיעו ל-500 לדקה; לאחר העברת resharding לחלון לילה, הם ירדו ל-50 לדקה. זמן האחזור באחוזון ה-95 עלה ל-120 אלפיות השנייה, ואז ירד ל-80 אלפיות השנייה לאחר השינוי. תכננו resharding בתקופות עומס נמוך — לדוגמה, בסופי שבוע.

בחירת מיקום ל-mongos

ניתן למקם mongos בשתי דרכים: כנתב ייעודי לצד כל יישום על localhost או על שרתים ייעודיים מאחורי מאזן עומסים. הראשון נותן זמן אחזור מינימלי אך מגדיל את מספר התהליכים לניהול. השני מפשט ניהול ותצורה אך מוסיף קפיצת רשת ונקודת כשל יחידה פוטנציאלית במאזן העומסים. אנו ממליצים על גישה היברידית: עבור שירותים קריטיים — mongos ייעודי לצד; עבור משימות רקע — מאגר משותף מאחורי HAProxy.

כיצד פתרנו בעיית נקודה חמה על mongos

בפרויקט לקוח אחד, העומס היה לא אחיד: חלק מהשאילתות פגעו בשרד חם. החלפנו round-robin ב-leastconn ב-HAProxy והגדלנו את taskExecutorPoolSize מ-4 ל-8 — זמני האחזור ירדו ב-30%. כוונון זה היה יעיל פי 2 מאשר פשוט הגדלת מספר מופעי mongos. mongos מוגדר כראוי עם HAProxy אמין פי 2 ממופע mongos יחיד. הגדרנו גם איסוף מדדים ב-Prometheus דרך mongos-exporter ולוח מחוונים ב-Grafana. כל השינויים יושמו דרך Ansible, מה שמבטיח חזרתיות. כתוצאה מכך, הלקוח חסך 40% מזמן האבחון ו-10,000 דולר בשנה, מה שהוביל לחיסכון משמעותי בעלויות.

תצורת mongos

ל-mongos אין storage בתצורה שלו — הוא אינו מאחסן נתונים. תצורה מינימלית:

---
sharding:
  configDB: configRS/cfg1.internal:27019,cfg2.internal:27019,cfg3.internal:27019
net:
  port: 27017
  bindIp: 0.0.0.0
  maxIncomingConnections: 2000
security:
  keyFile: /etc/mongodb/cluster-keyfile
systemLog:
  destination: file
  path: /var/log/mongodb/mongos.log
  logAppend: true
  verbosity: 0
operationProfiling:
  slowOpThresholdMs: 100
  mode: slowOp
setParameter:
  taskExecutorPoolSize: 4

חשוב: יש לחשב את sharding: configDB: configRS/cfg1.internal:27019,cfg2.internal:27019,cfg3.internal:27019 net: port: 27017 bindIp: 0.0.0.0 maxIncomingConnections: 2000 security: keyFile: /etc/mongodb/cluster-keyfile systemLog: destination: file path: /var/log/mongodb/mongos.log logAppend: true verbosity: 0 operationProfiling: slowOpThresholdMs: 100 mode: slowOp setParameter: taskExecutorPoolSize: 4 עם מרווח ביטחון — כל חיבור לקוח פותח עד N חיבורים לשרדים (N = מספר השרדים). עם 5 שרדים ו-2000 לקוחות, mongos מחזיק עד 10,000 חיבורים לשרדים. תצורת mongos כזו, בשילוב עם כוונון ביצועים נכון, מבטיחה זמינות גבוהה.

אימות וקובץ מפתח

כל רכיבי המקבץ — שרדים, שרתי תצורה ו-mongos — משתמשים באותו operationProfiling.slowOpThresholdMs: 50 לאימות בין-רכיבי.

openssl rand -base64 756 | tr -d '\n' > /etc/mongodb/cluster-keyfile
chmod 400 /etc/mongodb/cluster-keyfile
chown mongod:mongod /etc/mongodb/cluster-keyfile

אם קובץ המפתח אינו תואם, mongos לא יתחיל וידווח על keyFile. הגדרה נכונה של mongos כוללת הפצת קובץ מפתח על פני כל הצמתים.

ניטור ביצועי mongos

פקודות אבחון:

db.adminCommand({ serverStatus: 1 })
db.adminCommand({ currentOp: 1, active: true })
db.getSiblingDB("admin").system.profile.find({ millis: { $gt: 100 } }).sort({ ts: -1 }).limit(20)

ב-openssl rand -base64 756 | tr -d '\n' > /etc/mongodb/cluster-keyfile chmod 400 /etc/mongodb/cluster-keyfile chown mongod:mongod /etc/mongodb/cluster-keyfile , בדקו Authentication failed מול db.adminCommand({ serverStatus: 1 }) db.adminCommand({ currentOp: 1, active: true }) db.getSiblingDB("admin").system.profile.find({ millis: { $gt: 100 } }).sort({ ts: -1 }).limit(20) . אם serverStatus מתקרב לאפס — יש בעיה במאגר החיבורים או ש-connections.current נמוך מדי. אינכם יכולים לגשת ל-connections.available מ-mongos — אספו מדדי WiredTiger מצמתי השרד. זה לעיתים קרובות מוזנח. לכוונון ביצועים, השתמשו בפרופילינג של שאילתות איטיות דרך available. לכוונון ביצועים מתמשך של mongos, שלבו עם Prometheus ו-Grafana. צוות המומחים המוסמכים שלנו ב-MongoDB בעל ניסיון של שנים בהגדרת מקבצים מבוססי-שרדינג. אנו מבטיחים שיפור ביצועים של 30% או החזר כספי.

תיעוד הניטור הרשמי של MongoDB

תהליך העבודה

1. ניתוח: הערכת הארכיטקטורה הנוכחית, פרופיל עומס, זיהוי צווארי בקבוק.
2. תכנון: בחירת סכמת מיקום, חישוב משאבים, הכנת תצורות.
3. יישום: פריסת mongos, הגדרת קובץ מפתח, שילוב עם מאזן עומסים.
4. בדיקות: מבחני עומס, בדיקות סובלנות לתקלות, התאמות.
5. פריסה: עדכון מחרוזות חיבור ביישומים, ניטור במהלך היום הראשון.

לוחות זמנים: פריסת mongos כחלק ממקבץ — 1–2 ימים. ביקורת ואופטימיזציה של תצורה קיימת — 1–3 ימים.

מה כלול בעבודה

• תצורת mongos המותאמת לעומס שלכם.
• הגדרת HAProxy או nginx לאיזון עומסים.
• יצירה והפצה של קובץ מפתח.
• שילוב עם מערכת ניטור (Prometheus exporter, Grafana).
• תיעוד סכמת החיבור לצוות.
• הדרכה למהנדסי תורנות (runbook לבעיות נפוצות).

טעות נפוצה של מתחילים היא להשאיר את serverStatus על 0 לצמיתות. בעת אבחון, הגדילו אותו לפחות לרמה 1, ואז החזירו — זה עוזר לאתר את הבעיה מהר יותר.

הבטיחו זמינות גבוהה על ידי פריסת מספר מופעי mongos. עבור יישומים קריטיים, מקם mongos כנתב ייעודי. הגישה המוכחת שלנו נבדקה בסביבות ייצור עם למעלה מ-100 שרדים. קבלו ייעוץ על הגדרת mongos לפרויקט שלכם — המהנדסים המוסמכים שלנו יעזרו למנוע השבתה ולמטב ביצועים. הביקורת שלנו מתחילה ב-500 דולר ובדרך כלל חוסכת 5,000 דולר בשנה. צרו קשר לביקורת של תצורת mongos הקיימת שלכם — נמצא צווארי בקבוק ונציע תוכנית אופטימיזציה.