פריסה וניהול של עובדים

במאמר הזה מוסבר איך לפרוס, לשנות את קנה המידה, להוציא משימוש ולנטר עובדים של Spanner Omni במכונות וירטואליות (VM) וב-Kubernetes.

‫Workers הם צמתים ייעודיים של מחשוב ללא מצב (stateless) שנועדו להפחית את העומס על שרתי Spanner Omni שנוצר כתוצאה מפעולות ברקע שדורשות הרבה משאבים. העובדים לא מארחים נתוני משתמשים ולא משתתפים בבחירות של מנהיגים, בעסקאות או בפעילויות אחרות של מסד הנתונים. בניגוד לשרתים, ה-workers לא משויכים לאזור ספציפי. במקום זאת, העובדים נרשמים למיקום מסוים ויכולים להריץ משימות בכל אזור במיקום הזה. הוספה והסרה של עובדים הן פעולות קלות ומהירות כי העובדים הם בלי שמירת מצב ולא נדרש להעביר נתונים או לבצע איזון מחדש.

העובדים נדרשים ליצור אינדקסים של וקטורים בטבלאות גדולות (יותר ממיליון שורות) עבור שאילתות חיפוש של השכן הקרוב המשוער (ANN). מידע נוסף מופיע במאמר סקירה כללית על חיפוש וקטורי ב-Spanner Omni.

התכונה Workers זמינה רק במהדורה המסחרית של Spanner Omni. מהדורת המפתחים לא תומכת ב-Workers. החיוב על מחשוב של עובדים מתבצע באותו תעריף כמו על שרתים בפריסה (לכל vCPU). מידע נוסף זמין במאמר סקירה כללית על מהדורות Spanner Omni.

לפני שמתחילים

לפני שמוסיפים עובדים לפריסת Spanner Omni קיימת, צריך לוודא שהסביבה עומדת בדרישות הבאות:

  • מורידים ומגדירים את קובץ ההרצה של Spanner Omni.

  • פריסה קיימת: מוודאים שיש לכם פריסת Spanner Omni פעילה (לא פריסה של שרת יחיד) בסטטוס READY, שהוגדרה עם מהדורת Commercial. מהדורת Developer לא תומכת בעובדים. החיוב על השימוש בעובדים מתבצע באותו התעריף כמו החיוב על השרתים בפריסה. מידע נוסף זמין במאמר סקירה כללית על מהדורות Spanner Omni. חשוב לוודא שיש לכם את הפרטים הבאים:

    • שם המיקום הגיאוגרפי לטירגוט (לדוגמה, us-central1) כפי שהוגדר בהגדרות הפריסה.
    • נקודת הקצה של הפריסה (HOST:PORT, כמו my-spanner-deployment:15003) או רשימה של כתובות שרת הבסיס (ROOT_HOST_1:PORT,‏ ROOT_HOST_2:PORT, כמו root-server-1:15000, ‏ root-server-2:15000) לגילוי אשכולות.

  • משאבי מערכת וחומרה: מוודאים שמשאבי המחשוב שהקציתם לעובד מספיקים לביצוע הפעולות הנדרשות בפרק זמן סביר.

  • הגדרת vSphere: אם מריצים את Spanner Omni בפלטפורמת הווירטואליזציה vSphere, צריך להשבית את הווירטואליזציה של מונה חותמות הזמן (TSC). מוסיפים את monitor_control.virtual_rdtsc = FALSE לקובץ התצורה .vmx של המכונה הווירטואלית.

  • הגדרת הרשת וחומת האש: העובדים משתמשים ביציאה 15027 בנוסף ליציאות התקשורת הרגילות של השרת (15000 עד 15025). מוודאים שהגדרת הרשת מאפשרת תקשורת ביציאות 15000 עד 15027.

פריסת עובדים במכונות וירטואליות

כדי לפרוס עובדים במכונה וירטואלית (VM), מפעילים את תהליך העובד באמצעות נקודת הקצה של הפריסה או רשימה של שרתי הבסיס.

אפשרות א': התחלת השימוש בנקודת הקצה של הפריסה

כדי להפעיל Worker באמצעות נקודת הקצה של הפריסה, מריצים את הפקודה spanner workers start:

spanner workers start \
  --location=LOCATION_NAME \
  --address=WORKER_HOSTNAME:WORKER_PORT_BASE \
  --deployment=DEPLOYMENT_ENDPOINT \
  --base-dir=BASE_DIR \
  --license-file-path=LICENSE_FILE_PATH

מחליפים את מה שכתוב בשדות הבאים:

  • ‫LOCATION_NAME: שם מיקום היעד, לדוגמה us-central1.
  • WORKER_HOSTNAME: שם המארח או כתובת ה-IP של מכונת ה-Worker הווירטואלית שאפשר לפתור.
  • ‫WORKER_PORT_BASE: יציאת הבסיס שבה מופעל העובד. לדוגמה, 15000 או 20000.
  • ‫DEPLOYMENT_ENDPOINT: המארח והיציאה של נקודת הקצה של הפריסה, לדוגמה my-spanner-deployment:15003.
  • ‫BASE_DIR: ספריית הבסיס לנתוני העובדים וללוגים, לדוגמה /var/spanner.
  • ‫LICENSE_FILE_PATH: הנתיב לקובץ הרישיון של Spanner Omni.

אפשרות ב': מתחילים להשתמש ברשימה של שרתי בסיס

כדי להפעיל תהליך עובד באמצעות רשימה של שרתי root, מריצים את הפקודה spanner workers start:

spanner workers start \
  --location=LOCATION_NAME \
  --address=WORKER_HOSTNAME:WORKER_PORT_BASE \
  --join-servers=ROOT_SERVER_1_HOST:ROOT_SERVER_PORT_BASE,\
ROOT_SERVER_2_HOST:ROOT_SERVER_PORT_BASE \
  --base-dir=BASE_DIR \
  --license-file-path=LICENSE_FILE_PATH

מחליפים את מה שכתוב בשדות הבאים:

  • ‫LOCATION_NAME: שם מיקום היעד, לדוגמה us-central1.
  • WORKER_HOSTNAME: שם המארח או כתובת ה-IP של מכונת ה-Worker הווירטואלית שאפשר לפתור.
  • ‫WORKER_PORT_BASE: יציאת הבסיס שבה מופעל העובד. לדוגמה, 15000 או 20000.
  • ‫ROOT_SERVER_1_HOST,‏ ROOT_SERVER_2_HOST: שמות המארחים או כתובות ה-IP של שרתי הבסיס בפריסה.
  • ‫ROOT_SERVER_PORT_BASE: יציאת הבסיס של שרתי הבסיס, לדוגמה 15000.
  • ‫BASE_DIR: ספריית הבסיס לנתוני העובדים וללוגים, לדוגמה /var/spanner.
  • ‫LICENSE_FILE_PATH: הנתיב לקובץ הרישיון של Spanner Omni.

הגדרת הצפנה

אם הפריסה של Spanner Omni משתמשת בהצפנת TLS או mTLS, צריך להגדיר הצפנה לכל עובד:

  1. אם עדיין לא עשיתם את זה, צריך לעדכן את אישור השרת כך שיכלול את שמות המארחים של העובדים.
  2. מעתיקים את ספריית האישורים שמכילה את הקבצים ca.crt, server.crt ו-server.key ל-worker VM.

  3. מוסיפים את הדגל --certificate-directory כשמריצים את הפקודה spanner workers start:

    spanner workers start \
  --location=LOCATION_NAME \
  --address=WORKER_HOSTNAME:WORKER_PORT_BASE \
  --deployment=DEPLOYMENT_ENDPOINT \
  --base-dir=BASE_DIR \
  --certificate-directory=CERTIFICATE_DIRECTORY \
  --license-file-path=LICENSE_FILE_PATH

    מחליפים את CERTIFICATE_DIRECTORY בספרייה שמכילה את ca.crt, server.crt ו-server.key.

מידע נוסף על הגדרת אישורים ופריסות מאובטחות זמין במאמר יצירת פריסה מאובטחת במכונות וירטואליות.

פריסת עובדים ב-Kubernetes

בסביבות Kubernetes כמו Google Kubernetes Engine ‏ (GKE) או Amazon Elastic Kubernetes Service ‏ (Amazon EKS), אתם פורסים את העובדים כחלק מגרסת Spanner Omni Helm הקיימת שלכם באותו מרחב שמות כמו האשכול. תרשים Helm פורס עובדים כ-Kubernetes StatefulSet עם Service ללא ראש, ומעניק לכל פוד של עובד זהות רשת יציבה ו-PersistentVolumeClaims (תביעות של נפח אחסון מתמשך,‏ PVC), שמאפשרת לשרתי הבסיס לתקשר באופן מהימן עם כל עובד.

כברירת מחדל, תרשים Helm מתזמן פודים של עובדים רק בצמתים עם התווית spanner-role=workers, מאפשר את ההרעלה spanner-role=workers:NoSchedule ומריץ לכל היותר פוד אחד של עובד לכל צומת. לפני שמפעילים את העובדים, מוסיפים מאגר צמתים עם התווית וההגדרה הזו, שיש בו לפחות workers.replicas צמתים. לכל צומת צריך להיות מספיק מעבד (CPU) וזיכרון שניתן להקצאה בשביל פוד עובד אחד, כפי שמוגדר על ידי workers.resources.cpu ו-workers.resources.memory. ‫Kubernetes שומר חלק מהקיבולת של כל צומת לרכיבי מערכת, ולכן צריך לבחור צמתים גדולים יותר מהערכים האלה. כדי להשתמש בתווית אחרת, מגדירים את הערכים של workers.nodeLabelKey ושל workers.nodeLabelValue. כדי להסיר את הדרישה להוספת תווית, מגדירים את workers.nodeLabelKey="". כדי להחליף את כללי התזמון שמוגדרים כברירת מחדל, מגדירים את workers.affinity.

כדי להפעיל את העובדים בפריסה הקיימת, מריצים את הפקודה helm upgrade:

helm upgrade spanner-omni HELM_CHART_PATH \
  --reuse-values \
  --set workers.enabled=true \
  --namespace NAMESPACE

מחליפים את מה שכתוב בשדות הבאים:

  • ‫HELM_CHART_PATH: הנתיב לתרשים Helm של Spanner Omni.
  • ‫NAMESPACE: מרחב השמות של Kubernetes שבו פריסת אשכול Spanner Omni מתבצעת, לדוגמה spanner-ns.

כדי לאפשר לעובדים לפעול בכל צומת שיש בו מספיק מעבד (CPU) וזיכרון להקצאה, מגדירים את workers.nodeLabelKey כמחרוזת ריקה. הפעולה הזו מסירה גם את הדרישה לתווית הצומת וגם את הסבילות לכתם:

helm upgrade spanner-omni HELM_CHART_PATH \
  --reuse-values \
  --set workers.enabled=true \
  --set workers.nodeLabelKey="" \
  --namespace NAMESPACE

הגדרות אופציונליות כוללות:

  • ‫--set workers.replicas=WORKER_REPLICAS: מספר העותקים המשוכפלים של העובדים שצריך לפרוס. ערך ברירת המחדל הוא 1.

  • ‫--set workers.resources.cpu=CPU_CORES: מגבלת ה-CPU והבקשה לכל עובד. ערך ברירת המחדל הוא 6.

  • ‫--set workers.resources.memory=MEMORY_LIMIT: מגבלת הזיכרון והבקשה של כל עובד. ערך ברירת המחדל הוא 24Gi.

  • ‫--set workers.storage.size=STORAGE_SIZE: קיבולת האחסון של כל עובד. ערך ברירת המחדל הוא 20Gi.

  • ‫--set workers.storage.storageClassName=STORAGE_CLASS: סוג האחסון לשימוש באחסון של העובדים – לדוגמה, hyperdisk-balanced-rwo ב-GKE או aws-gp3 ב-Amazon EKS. ברירת המחדל היא מחרוזת ריקה, שבה מוגדר סוג האחסון (storage class) שמוגדר כברירת מחדל באשכול.

  • ‫--set workers.port=WORKER_PORT: יציאת הרשת שהתהליך של העובד מאזין לה. ברירת המחדל היא deployment.basePort, כלומר 15000.

  • ‫--set workers.joinServers={ROOT_HOST_1:PORT,ROOT_HOST_2:PORT}: רשימה מופרדת בפסיקים של כתובות שרתי הבסיס להצטרפות. ברירת המחדל היא רשימה ריקה ([]), שבה מתבצעת גילוי של כל שרתי הבסיס הפעילים מטופולוגיית הפריסה.

  • ‫--set workers.nodeLabelKey=NODE_LABEL_KEY: מפתח התווית של צומת Kubernetes שמשמש להעדפת צמתים ולסבילות כדי לבודד את העובדים למאגר צמתים ייעודי. ערך ברירת המחדל הוא spanner-role. מגדירים מחרוזת ריקה "" כדי להשבית את הזיקה של הצומת ואת ההרשאות.

  • ‫--set workers.nodeLabelValue=NODE_LABEL_VALUE: הערך של התווית של צומת Kubernetes שמשמשת להעדפת צומת ולסבילות. ערך ברירת המחדל הוא workers.

  • ‫--set workers.pdbMaxUnavailable=MAX_UNAVAILABLE: המספר המקסימלי של פודים של עובדים שיכולים להיות לא זמינים במהלך שיבושים מרצון ב-PodDisruptionBudget. ערך ברירת המחדל הוא 1.

  • ‫workers.affinity: כללי שיוך מותאמים אישית של Kubernetes ל-pods של העובדים. אם לא מציינים ערך, מוחלת זיקה של צומת שמוגדרת כברירת מחדל (באמצעות workers.nodeLabelKey ו-workers.nodeLabelValue) ואנטי-זיקה של פודים בין שמות מארחים (kubernetes.io/hostname). מכיוון שמדובר באובייקט מקונן, צריך לציין אותו בקובץ values.yaml באמצעות הדגל -f.

אימות הפריסה של העובד

כדי לוודא שפודים של העובדים פועלים ומוכנים, מריצים את הפקודה הבאה:

kubectl get pods --namespace NAMESPACE -l app.kubernetes.io/component=spanner-worker

הגדלה והוצאה משימוש של עובדים

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

אוטומציה של שינוי מספר העובדים

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

הוצאה משימוש של מכונת עבודה וירטואלית

כדי להפסיק תהליך של עובד שפועל במכונה וירטואלית, לוחצים על Control+C במסוף שבו פועל התהליך של העובד, או מפסיקים את התהליך באמצעות מזהה התהליך (PID):

kill -TERM PID

מחליפים את PID במזהה התהליך של התהליך spanner workers. אפשרות אחרת היא לכבות את מכונת ה-VM של העובד.

הוצאה משימוש של worker ב-Kubernetes

כדי להוציא משימוש עובדים ב-Kubernetes, משביתים את העובדים בגרסת Helm או מצמצמים את מספר העותקים של העובדים ישירות באמצעות kubectl:

  • השבתת עובדים: כדי להסיר את העובד StatefulSet ואת השירות מהאשכול תוך שמירה על שאר הפריסה, מריצים את הפקודה helm upgrade עם workers.enabled=false:

    helm upgrade spanner-omni HELM_CHART_PATH \
  --reuse-values \
  --set workers.enabled=false \
  --namespace NAMESPACE

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫HELM_CHART_PATH: הנתיב לתרשים Helm של Spanner Omni.
    • ‫NAMESPACE: מרחב השמות של Kubernetes שבו פריסת אשכול Spanner Omni מתבצעת, לדוגמה spanner-ns.

  • הקטנת מספר העותקים של העובדים: כדי להקטין את מספר העותקים של פודים של עובדים לאפס, תוך שמירה על ההגדרות של העובדים כפעילות באשכול, מריצים את הפקודה kubectl scale:

    kubectl scale statefulset spanner-worker \
  --replicas=0 \
  --namespace NAMESPACE

    מחליפים את NAMESPACE במרחב השמות של Kubernetes שבו פריסת אשכול Spanner Omni מתבצעת – לדוגמה, spanner-ns.

מעקב אחרי עובדים ופתרון בעיות

אם הפריסה שלכם כוללת מעקב, תוכלו לעקוב אחרי העובדים באמצעות לוחות הבקרה של Prometheus או Grafana. ‫Workers חושפים מדדים דומים לשרתי Spanner Omni. לוחות הבקרה של Grafana כוללים לוח בקרה של Worker Insights שמאפשר לעקוב אחרי ניצול המשאבים של כל עובד.

תהליכי Worker כותבים קובצי יומן לספריית המשנה logs בתוך ספריית הבסיס שצוינה על ידי --base-dir:

BASE_DIR/logs

הפקודה spanner admin diagnostics create לא אוספת יומנים או נתוני אבחון מהעובדים. כדי לבדוק את היומנים של העובדים, אפשר לראות את הקבצים ב-BASE_DIR/logs ישירות במכונת העובד או ב-Pod, או להריץ את הפקודה kubectl logs עבור קבוצות Pod של עובדים ב-Kubernetes.

מידע נוסף על מעקב והגדרת מרכזי בקרה זמין במאמרים סקירה כללית של מעקב ומעקב באמצעות מרכזי בקרה של Grafana.

יצירת אינדקס וקטורי לא מתקדמת

אם יוצרים אינדקס וקטורי בטבלה גדולה והיצירה של האינדקס נשארת בהמתנה ללא התקדמות, צריך לוודא שלפחות עובד אחד פועל ומחובר לפריסה.

‫Spanner Omni מאפשר ליצור אינדקס וקטורי גם כשאין עובדים פעילים, כך שאפשר לפרוס עובדים רק כשנדרש. אם אין עובד פעיל, פעולת יצירת האינדקס מושהית ללא הגבלת זמן עד לפריסת עובד. אחרי שעובד מתחיל ונרשם בפריסה, יצירת האינדקס מתחדשת באופן אוטומטי.