סקירה כללית על פריסת עומסי עבודה של מכונות וירטואליות

במדריך הזה מוסבר על ההקשר הנדרש לפריסת עומס עבודה שמבוסס על מכונה וירטואלית (VM) באשכול מבודד (air-gapped) של Google Distributed Cloud ‏(GDC) על מתכת חשופה (bare metal) באמצעות סביבת זמן ריצה של מכונה וירטואלית. עומס העבודה במדריך הזה הוא פלטפורמה לדוגמה של מערכת כרטוס שזמינה בחומרה מקומית.

ארכיטקטורה

היררכיית המשאבים

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

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

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

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

Networking

כדי להפעיל את מערכת הכרטיסים בסביבת ייצור, צריך לפרוס שני שרתים של אפליקציות או יותר כדי להשיג זמינות גבוהה במקרה של כשל בצומת. בנוסף, הטופולוגיה הזו מאפשרת להפיץ את העומס על פני כמה מכונות כדי להרחיב את האפליקציה באופן אופקי. פלטפורמת GDC מבוססת Kubernetes ומשתמשת ב-Cloud Service Mesh כדי לנתב תעבורה בצורה מאובטחת לשרתי האפליקציות שמרכיבים את מערכת הכרטיסים.

‫Cloud Service Mesh הוא הטמעה של Google שמבוססת על פרויקט קוד פתוח שמנהל, מתעד ומאבטח שירותים. התכונות הבאות של Cloud Service Mesh מנוצלות כדי לארח את מערכת הכרטיסים ב-GDC:

• איזון עומסים: Cloud Service Mesh מפריד בין זרימת התנועה לבין שינוי גודל התשתית, ומאפשר שימוש בהרבה תכונות לניהול תנועה, כולל ניתוב דינמי של בקשות. מערכת הכרטיסים דורשת חיבורי לקוח קבועים, ולכן אנחנו מפעילים סשנים קבועים באמצעות DestinationRules כדי להגדיר את התנהגות ניתוב התנועה.

• סיום TLS: Cloud Service Mesh חושף שערים של תעבורת נתונים נכנסת באמצעות אישורי TLS ומספק אימות של תעבורת נתונים בתוך האשכול באמצעות mTLS (אבטחת שכבת תעבורה הדדית), בלי לשנות קוד אפליקציה כלשהו.

• שחזור לאחר כשל: Cloud Service Mesh מספק מספר תכונות קריטיות לשחזור לאחר כשל, כולל פסק זמן, מפסקי זרם, בדיקות תקינות פעילות וניסיונות חוזרים מוגבלים.

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

apiVersion: v1
kind: Service
metadata:
  name: http-ingress
spec:
  selector:
    app.kubernetes.io/component: application-server
  ports:
  - name: http
    port: 80
---
apiVersion: v1
kind: Service
metadata:
  name: database-ingress
spec:
  selector:
    app.kubernetes.io/component: database-server
  ports:
  - name: mysql
    port: 3306

Compute

מערכת הכרטוס ממליצה להשתמש במכונות Bare Metal או במכונות וירטואליות כדי לארח התקנות מקומיות, והשתמשנו בניהול מכונות וירטואליות (VM) של GDC כדי לפרוס את שרתי האפליקציות ושרתי מסדי הנתונים כעומסי עבודה של מכונות וירטואליות. הגדרת משאבי Kubernetes אפשרה לנו לציין גם את VirtualMachine וגם את VirtualMachineDisk כדי להתאים את המשאבים לצרכים שלנו בסוגים השונים של השרתים. ‫VirtualMachineExternalAccess מאפשר לנו להגדיר העברת נתונים אל המכונה הווירטואלית והעברת נתונים ממנה.

apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineDisk
metadata:
  name: vm1-boot-disk
spec:
  size: 100G
  source:
    image:
      name: ts-ticketing-system-app-server-2023-08-18-203258
      namespace: vm-system
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachine
metadata:
  labels:
    app.kubernetes.io/component: application-server
  name: vm1
  namespace: support
spec:
  compute:
    vcpus: 8
    memory: 12G
  disks:
  - boot: true
    virtualMachineDiskRef:
      name: vm1-boot-disk

---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineExternalAccess
metadata:
  name: vm1
  namespace: support
spec:
  enabled: true
  ports:
   - name: ssh
     protocol: TCP
     port: 22

עבור תמונת מערכת ההפעלה של האורח, יצרנו תמונה בהתאמה אישית כדי לעמוד בדרישות שלנו בנוגע לתאימות ולאבטחה. אפשר להתחבר למכונות וירטואליות שפועלות באמצעות SSH באמצעות VirtualMachineAccessRequest, וכך להגביל את היכולת להתחבר למכונות וירטואליות באמצעות Kubernetes RBAC, ולמנוע את הצורך ליצור חשבונות משתמש מקומיים בתמונות בהתאמה אישית. בבקשת הגישה מוגדר גם זמן חיים (TTL) שמאפשר לנהל את המכונות הווירטואליות באמצעות בקשות גישה מבוססות-זמן שפגות אוטומטית.

אוטומציה

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

פייפליין של גרסה

התאמה אישית של קובצי האימג' של שרת האפליקציות ושרת מסד הנתונים מתחילה מקובץ אימג' של מערכת הפעלה בסיסית. צריך לשנות את קובץ האימג' הבסיסי לפי הצורך כדי להתקין את יחסי התלות שנדרשים לכל קובץ אימג' של שרת. בחרנו תמונה של מערכת הפעלה בסיסית כי היא נפוצה מאוד ומארחת מערכות כרטוס בהתקנות מקומיות. תמונת מערכת ההפעלה הבסיסית הזו מספקת גם יכולות חיזוק אבטחה שנדרשות כדי לעמוד בדרישות של Security Technical Implementation Guides (מדריכים טכניים להטמעה של אבטחה, STIGs) שנדרשים כדי לספק תמונה תואמת שעומדת באמצעי הבקרה של NIST-800-53.

צינור העיבוד של האינטגרציה הרציפה (CI) שלנו השתמש בתהליך העבודה הבא כדי להתאים אישית תמונות של שרתים של אפליקציות ומסדי נתונים:

כשהמפתחים מבצעים שינויים בסקריפטים של ההתאמה האישית או בתלות של התמונות, אנחנו מפעילים תהליך עבודה אוטומטי בכלי CI שלנו כדי ליצור קבוצה חדשה של תמונות שמצורפות למהדורות של GDC. במסגרת בניית התמונה, אנחנו גם מרעננים את התלות במערכת ההפעלה (yum update) ומדללים את התמונה באמצעות דחיסה כדי לצמצם את גודל התמונה שנדרש להעברת תמונות לסביבות של לקוחות.

מחזור החיים של פיתוח תוכנה

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

פריסת מופע נפרד של מערכת הכרטיסים לכל פרויקט GDC אפשרה לנו לבדוק שינויים בבידוד, בלי להשפיע על מופעים קיימים באותו מופע GDC. השתמשנו ב-ResourceManager API כדי ליצור ולבטל פרויקטים באופן הצהרתי באמצעות משאבי Kubernetes.

apiVersion: resourcemanager.gdc.goog/v1
kind: Project
metadata:
  name: ticketing-system-dev
---
apiVersion: resourcemanager.gdc.goog/v1
kind: Project
metadata:
  name: ticketing-system-qa
---
apiVersion: resourcemanager.gdc.goog/v1
kind: Project
metadata:
  name: ticketing-system-staging

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

יכולת פעולה

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

מעקב

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

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

apiVersion: monitoring.gdc.goog/v1
kind: MonitoringTarget
metadata:
  name: database-monitor
spec:
  podMetricsEndpoints:
    path:
      value: /metrics
    port:
      annotation: application.io/dbMetrics
    scrapeInterval: 60s

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

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

מצבי כשל

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

apiVersion: monitoring.gdc.goog/v1
kind: MonitoringRule
metadata:
  name: monitoring-rule
spec:
  interval: 60s
  limit: 0
  alertRules:
  - alert: vm1_disk_usage
    expr:
      (node_filesystem_size_bytes{container_name="compute"} -
      node_filesystem_avail_bytes{container_name="compute"}) * 100 /
      node_filesystem_size_bytes{container_name="compute"} > 90
    labels:
      severity: error
      code: <a href="/distributed-cloud/hosted/docs/latest/gdcag/gdcag-io/service-manual/ts/runbooks/ts-r0001">TS-R0001</a>
      resource: vm1
    annotations:
      message: "vm1 disk usage above 90% utilization"

אחרי שווידאנו שהמערכת יציבה, העברנו את המיקוד למצבי כשל באפליקציה במערכת הכרטיסים. מכיוון שבדרך כלל נדרש מאיתנו להשתמש ב-Secure Shell ‏ (SSH) כדי להיכנס לכל מכונת VM של שרת אפליקציות כדי לבדוק את היומנים של מערכת הכרטיסים, הגדרנו אפליקציה להעברת היומנים האלה לכלי הרישום ביומן כדי לבנות על חבילת הכלים של GDC לצפייה ולשאילת כל היומנים התפעוליים של מערכת הכרטיסים במופע המעקב.

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

גיבויים

גיבויים חשובים לתפעול של מערכת תוכנה כי הם מאפשרים לשחזר את המערכת במקרה של כשל. ‫GDC מציע גיבוי ושחזור של מכונות וירטואליות באמצעות משאבי Kubernetes. יצירת משאב מותאם אישית VirtualMachineBackupRequest עם משאב מותאם אישית VirtualMachineBackupPlanTemplate מאפשרת לנו לגבות את נפח האחסון הקבוע שמצורף לכל מכונה וירטואלית לאחסון אובייקטים, שבו הגיבויים יכולים להישמר בהתאם למדיניות שמירת נתונים שהוגדרה.

apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineBackupPlanTemplate
metadata:
  name: vm-backup-plan
spec:
  backupRepository: "backup-repository"
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineBackupRequest
metadata:
  name: "db-vm-backup"
spec:
  virtualMachineBackupPlanTemplate: vm-backup-plan
  virtualMachine: db1
  virtualMachineBackupName: db-vm-backup

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

apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineRestoreRequest
metadata:
  name: vm-restore-1
spec:
  virtualMachineBackup: db-vm-backup
  restoreName: restore1
  restoredResourceName: db1

שדרוגים

כדי לתמוך במחזור החיים של התוכנה של מערכת הכרטיסים והתלות שלה, זיהינו שלושה סוגים של שדרוגי תוכנה, שכל אחד מהם מטופל בנפרד כדי למזער את זמן ההשבתה והשיבושים בשירות:

1. שדרוגי מערכת הפעלה.
2. שדרוגים של הפלטפורמה, כמו תיקון וגרסאות מרכזיות.
3. עדכוני הגדרות.

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

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

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

שילובים

ספקי זהויות

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

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

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

הוספת התראות

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

כדי להשיג את השילוב הזה, התאמנו אישית webhook של Kubernetes בקוד פתוח כדי לקבל התראות מהאפליקציה ולנהל את מחזור החיים של אירועים באמצעות נקודת קצה ל-API של מערכת הכרטיסים, שנחשפת דרך Cloud Service Mesh.

מפתחות ה-API מאוחסנים באמצעות מאגר הסודות של GDC, שמגובה בסודות של Kubernetes שמנוהלים באמצעות בקרת גישה מבוססת-תפקידים (RBAC). הגדרות אחרות, כמו נקודות קצה של API ושדות להתאמה אישית של אירועים, מנוהלות באמצעות אחסון של זוגות מפתח/ערך ב-ConfigMap של Kubernetes.

אימייל

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

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  name: allow-ingress-traffic-from-ticketing-system
spec:
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projects:
        matchNames:
        - ticketing-system

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

תאימות

רישום ביומן ביקורת

יומני ביקורת תורמים לסטטוס העמידה בהוראות הדין, כי הם מאפשרים לעקוב אחרי השימוש בתוכנה ולנטר אותו, ומספקים תיעוד של פעילות המערכת. יומני ביקורת מתעדים ניסיונות גישה של משתמשים לא מורשים, עוקבים אחרי השימוש בממשקי API ומזהים סיכוני אבטחה פוטנציאליים. יומני הביקורת עומדים בדרישות התאימות, כמו אלה שמוטלות על ידי Health Insurance Portability and Accountability Act (חוק היבילות ואחריות הדיווח של ביטוח בריאות (HIPAA)),‏ Payment Card Industry Data Security Standard (תקן אבטחת הנתונים המקובל בתעשיית כרטיסי תשלום (PCI DSS)) ו-Sarbanes-Oxley Act (חוק סרבנס-אוקסלי (SOX)).

‫GDC מספקת מערכת לתיעוד פעילויות אדמין וגישות בפלטפורמה, ולשמירת היומנים האלה למשך תקופה שניתנת להגדרה. פריסת המשאב המותאם אישית AuditLoggingTarget מגדירה את צינור הנתונים של הרישום ביומן לאיסוף יומני ביקורת מהאפליקציה שלנו.

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

בקרת גישה

בקרת גישה היא תהליך של הענקת גישה למשאבים או דחיית גישה למשאבים על סמך הזהות של המשתמש או התהליך שמבקשים גישה. כך אנחנו מגנים על הנתונים מפני גישה לא מורשית, ומוודאים שרק משתמשים מורשים יכולים לבצע שינויים במערכת. ב-GDC, אנחנו מסתמכים על Kubernetes RBAC כדי להצהיר על מדיניות ולאכוף הרשאות למשאבי המערכת שכוללים את אפליקציית מערכת הכרטיסים.

הגדרת ProjectRole ב-GDC מאפשרת לנו להעניק גישה מדויקת למשאבי Kubernetes באמצעות תפקיד הרשאה מוגדר מראש.

apiVersion: resourcemanager.gdc.goog/v1
kind: ProjectRole
metadata:
  name: ticketing-system-admin
  labels:
    resourcemanager.gdc.goog/rbac-selector: system
spec:
  rules:
  - apiGroups:
    - ""
    resources:
    - configmaps
    - events
    - pods/log
    - services
    verbs:
    - get
    - list

תוכנית התאוששות מאסון (DR)

שכפול מסד נתונים

כדי לעמוד בדרישות של התאוששות מאסון (DR), אנחנו פורסים את מערכת הכרטיסים בתצורת primary-secondary (ראשי-משני) בכמה מופעים של GDC. במצב הזה, בקשות למערכת ניהול הפניות מנותבות בדרך כלל לאתר הראשי, בזמן שהאתר המשני משכפל באופן רציף את יומן הרישום הבינארי של מסד הנתונים. במקרה של מעבר לגיבוי, האתר המשני הופך לאתר הראשי החדש, והבקשות מנותבות לאתר הראשי החדש.

אנחנו מסתמכים על יכולות שכפול של מסדי נתונים כדי להגדיר את שרתי מסד הנתונים הראשיים ושרתי מסד הנתונים המשוכפלים לכל מופע של GDC על סמך הפרמטרים שהוגדרו.

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

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

1. מפעילים את היומן הבינארי.

2. מגדירים את מזהה השרת.

3. יוצרים חשבון משתמש לשכפול.

4. יוצרים גיבוי.

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

1. מגדירים את מזהה השרת.

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

3. שחזור מגיבוי של מיקום ביומן בינארי של חידוש.

שכפול מסד נתונים דורש קישוריות לרשת כדי שהעותק יוכל להתחבר למסד הנתונים הראשי ולהתחיל בשכפול. כדי לחשוף את נקודת הקצה של מסד הנתונים הראשי לשכפול, אנחנו משתמשים ב-Cloud Service Mesh כדי ליצור רשת שירותים של Ingress שתומכת בסיום TLS ברשת השירותים, בדומה לאופן שבו אנחנו מטפלים בהעברת נתונים באמצעות HTTPS באפליקציית האינטרנט של מערכת הכרטיסים.