שיטות מומלצות לזמינות גבוהה ב-OpenShift

במסמך הזה מפורטות שיטות מומלצות להשגת זמינות גבוהה (HA) של עומסי עבודה של Red Hat OpenShift Container Platform ב-Compute Engine. במאמר הזה נתמקד באסטרטגיות ברמת האפליקציה שיעזרו לכם לוודא שעומסי העבודה שלכם יישארו עם זמינות גבוהה במקרה של כשלים. האסטרטגיות האלה עוזרות לכם למנוע נקודות כשל בודדות ולהטמיע מנגנונים למעבר גיבוי אוטומטי ולשחזור.

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

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

פריסת פריסות בכמה אזורים

מומלץ לפרוס את OpenShift בכמה אזורים בתוך אזורGoogle Cloud . הגישה הזו עוזרת לוודא שאם אזור מסוים חווה הפסקה זמנית בשירות, צמתי מישור הבקרה של האשכול ימשיכו לפעול באזורים האחרים שבהם הפריסה מתבצעת. כדי לפרוס את OpenShift בכמה אזורים, צריך לציין רשימה של אזורים מאותו אזור בקובץ install-config.yaml. Google Cloud

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

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

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: my-app-namespace
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      # Pod Anti-Affinity: Prefer to schedule new pods on nodes in different zones.
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: my-app
            topologyKey: topology.kubernetes.io/zone
      containers:
      - name: my-app-container
        image: quay.io/myorg/my-app:latest
        ports:
        - containerPort: 8080

בשירותים חסרי מצב (stateless) כמו ממשקי קצה של אתרים או ממשקי API של REST, מומלץ להפעיל כמה עותקים משוכפלים של פודים לכל שירות או מסלול. הגישה הזו מבטיחה שהתנועה תנותב אוטומטית לתאי שרתים באזורים זמינים.

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

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

מומלץ גם להשתמש בשירותים הבאים של איזון עומסים:

  • OpenShift ingress operator. אופרטור Ingress פורס בקרי Ingress מבוססי HAProxy כדי לטפל בהפניה של תעבורה אל הפודים. בפרט, מומלץ להגדיר גישה גלובלית לבקר Ingress, כדי לאפשר ללקוחות בכל אזור באותה רשת VPC ובאותו אזור כמו מאזן העומסים, להגיע לעומסי העבודה שפועלים באשכול. בנוסף, מומלץ להטמיע בדיקות תקינות של בקר ה-Ingress כדי לעקוב אחרי התקינות של הפודים ולהפעיל מחדש פודים שנכשלו.
  • ‫Google Cloud Load Balancing. איזון העומסים מפזר את התעבורה ביןGoogle Cloud אזורים. בוחרים מאזן עומסים שעונה על הצרכים של האפליקציה.

הגדרת תקציבים לשיבוש Pod

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

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
  namespace: my-app-namespace
spec:
  # Define how many pods need to remain available during a disruption.
  # At least one of "minAvailable" or "maxUnavailable" must be specified.
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

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

שימוש באחסון שתומך בזמינות גבוהה (HA) וברפליקציית נתונים

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

שיטות מומלצות לשימוש בדיסקים

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

אחרי שבוחרים אפשרות אחסון, מתקינים את מנהל ההתקן שלה באשכול:

אופרטור ה-CSI Persistent Disk מספק סוג אחסון (storage class) שאפשר להשתמש בו כדי ליצור הצהרות על נפחי אחסון מתמיד (PVC). ב-Filestore, צריך ליצור את סוג האחסון של Filestore.

שיטות מומלצות לשימוש במסדי נתונים

אם אתם צריכים מסד נתונים, אתם יכולים להשתמש באחד מהמסדים הבאים:

  • מסד נתונים מנוהל: מומלץ להשתמש ב-Cloud SQL או ב-AlloyDB ל-PostgreSQL כדי לנהל את הזמינות הגבוהה של מסד הנתונים בשמכם. אם אתם משתמשים ב-Cloud SQL, אתם יכולים להשתמש בCloud SQL Proxy Operator כדי לפשט את ניהול החיבורים בין האפליקציה לבין מסד הנתונים.
  • מסד נתונים בניהול עצמי: מומלץ להשתמש במסד נתונים שתומך בזמינות גבוהה (HA) ולפרוס את האופרטור שלו כדי להפעיל זמינות גבוהה. למידע נוסף, אפשר לעיין במסמכים שקשורים לאופרטור של מסד הנתונים, כמו Redis Enterprise for Kubernetes,‏ MariaDB Operator או CloudNative PostgreSQL Operator.

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

  • נוצר אשכול PostgreSQL בשם my-postgres-cluster עם שלוש מכונות לזמינות גבוהה.
  • האשכול משתמש בregionalpd-balanced מחלקת אחסון לאחסון עמיד ומשוכפל באזורים שונים.
  • מסד נתונים בשם mydatabase מאותחל עם משתמש myuser, כשהאישורים שלו מאוחסנים בסוד של Kubernetes שנקרא my-database-secret.
  • הגישה למשתמש על מושבתת כדי לשפר את האבטחה.
  • המעקב מופעל באשכול.
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: my-postgres-cluster
  namespace: postgres-namespace
spec:
  instances: 3
  storage:
    size: 10Gi
    storageClass: regionalpd-balanced
  bootstrap:
    initdb:
      database: mydatabase
      owner: myuser
      secret:
        name: my-database-secret
  enableSuperuserAccess: false
  monitoring:
    enabled: true
---
apiVersion: 1
kind: Secret
metadata:
  name: my-database-secret
  namespace: postgres-namespace
type: Opaque
data:
  username: bXl1c2Vy # Base64-encoded value of "myuser"
  password: c2VjdXJlcGFzc3dvcmQ= # Base64-encoded value of "securepassword"

העברת מצב האפליקציה אל מחוץ לאפליקציה

מומלץ להעביר את מצב הסשן או את הנתונים שבמטמון למאגרי נתונים משותפים בזיכרון (לדוגמה, Redis) או למאגרי נתונים קבועים (לדוגמה, Postgres, ‏ MySQL) שמוגדרים לפעול במצב HA.

סיכום של השיטות המומלצות

לסיכום, כדי להשיג זמינות גבוהה עם OpenShift, כדאי להטמיע את השיטות המומלצות הבאות:

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

המאמרים הבאים