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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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