שיטות מומלצות לזמינות גבוהה ב-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, מומלץ להפעיל כמה רפליקות של פודים לכל שירות או מסלול. הגישה הזו מבטיחה שהתנועה תנותב אוטומטית לתאי שרתים באזורים זמינים.

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

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

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

  • OpenShift ingress operator. מפעיל Ingress פורס בקרי Ingress מבוססי HAProxy כדי לטפל בניתוב לפודים. בפרט, מומלץ להגדיר גישה גלובלית לבקר Ingress, כדי לאפשר ללקוחות בכל אזור באותה רשת VPC ובאותו אזור כמו מאזן העומסים, להגיע לעומסי העבודה שפועלים באשכול. בנוסף, מומלץ להטמיע בדיקות תקינות של בקר הכניסה כדי לעקוב אחרי התקינות של הפודים ולהפעיל מחדש פודים שנכשלים.
  • ‫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 מספק מחלקת אחסון שאפשר להשתמש בה כדי ליצור הצהרות על נפחי אחסון מתמיד (PVC). ב-Filestore, צריך ליצור את סוג האחסון של Filestore.

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

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

  • מסד נתונים מנוהל: מומלץ להשתמש ב-Cloud SQL או ב-AlloyDB ל-PostgreSQL כדי לנהל את הזמינות הגבוהה של מסד הנתונים בשמכם. אם אתם משתמשים ב-Cloud SQL, אתם יכולים להשתמש בCloud SQL Proxy Operator כדי לפשט את ניהול החיבור בין האפליקציה לבין מסד הנתונים.
  • מסד נתונים בניהול עצמי: מומלץ להשתמש במסד נתונים שתומך בזמינות גבוהה (HA) ולפרוס את האופרטור שלו כדי להפעיל זמינות גבוהה. מידע נוסף מופיע במסמכי התיעוד שקשורים לאופרטור של מסד הנתונים, כמו AlloyDB Omni for Kubernetes,‏ 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
  • שימוש בתכונות של שכפול נתונים לזמינות גבוהה
  • העברת מצב האפליקציה אל מחוץ לאפליקציה

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