שיפור הביצועים של האחסון באמצעות Hyperdisk

מנהל ההתקן של ה-CSI של Compute Engine Persistent Disk הוא הדרך העיקרית שלכם לגשת לאחסון Hyperdisk באמצעות אשכולות Google Kubernetes Engine ‏ (GKE).

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

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

  • מפעילים את ממשק Google Kubernetes Engine API.
  • הפעלת Google Kubernetes Engine API
  • אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.

דרישות

כדי להשתמש בנפחי Hyperdisk ב-GKE, האשכולות צריכים לעמוד בדרישות הבאות:

  • להשתמש באשכולות Linux שמריצים GKE בגרסה 1.26 ואילך. אם אתם משתמשים בערוץ הפצה, צריך לוודא שהגרסה של GKE בערוץ היא הגרסה המינימלית שנדרשת למנהל ההתקן הזה או גרסה חדשה יותר. כדי להקצות נפחי אחסון של Hyperdisk Balanced High Availability נדרשת גרסה 1.33 ואילך של GKE.
  • מוודאים שהדרייבר של Compute Engine Persistent Disk CSI מופעל. הדרייבר של Persistent Disk ב-Compute Engine מופעל כברירת מחדל באשכולות חדשים במצב Autopilot ובמצב Standard, ואי אפשר להשבית או לערוך אותו כשמשתמשים ב-Autopilot. אם אתם צריכים להפעיל את מנהל ה-CSI של Persistent Disk ב-Compute Engine מהאשכול, תוכלו לעיין במאמר בנושא הפעלת מנהל ה-CSI של Persistent Disk ב-Compute Engine באשכול קיים.

יצירת נפח אחסון של Hyperdisk ל-GKE

בקטע הזה מוסבר איך ליצור נפח Hyperdisk שמגובה על ידי מנהל התקן CSI של Compute Engine ב-GKE.

יצירת StorageClass

השדות הבאים של אחסון ב-Persistent Disk‏ Type מסופקים על ידי מנהל התקן CSI של Persistent Disk ב-Compute Engine כדי לתמוך ב-Hyperdisk:

  • hyperdisk-balanced
  • hyperdisk-throughput
  • hyperdisk-extreme
  • hyperdisk-ml
  • hyperdisk-balanced-high-availability

כדי ליצור StorageClass חדש עם רמת התפוקה או ה-IOPS הרצויה, משתמשים ב-pd.csi.storage.gke.io בשדה של מנהל הקצאות (provisioner), ומציינים אחד מסוגי האחסון של Hyperdisk.

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

פרמטר Hyperdisk Type Usage
provisioned-throughput-on-create ‫Hyperdisk Balanced*, ‏ Hyperdisk Balanced High Availability, ‏ Hyperdisk Throughput מציינים את ערך התפוקה ב-MiB/s באמצעות המאפיין Mi. לדוגמה, אם התפוקה הנדרשת היא 250 MiB/s, מציינים "250Mi" כשיוצרים את StorageClass.
provisioned-iops-on-create ‫Hyperdisk Balanced, ‏ Hyperdisk Balanced High Availability, ‏ Hyperdisk Extreme ערך ה-IOPS צריך להיות ללא תוספות. לדוגמה, אם אתם צריכים 7,000 IOPS, צריך לציין "7000" כשיוצרים את StorageClass.
* אם אתם צריכים אבטחה משופרת ומתכננים להשתמש ב-Confidential Google Kubernetes Engine Nodes, כדאי ליצור מצב סודי ל-Hyperdisk Balanced, לעיין במגבלות נוספות של מצב סודי ל-Hyperdisk Balanced ולקרוא מידע נוסף על Confidential Google Kubernetes Engine Nodes.

בדוגמאות הבאות אפשר לראות איך יוצרים StorageClass לכל סוג של Hyperdisk:

Hyperdisk Balanced

  1. שומרים את המניפסט הבא בקובץ בשם hdb-example-class.yaml:

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: balanced-storage
    provisioner: pd.csi.storage.gke.io
    volumeBindingMode: WaitForFirstConsumer
    allowVolumeExpansion: true
    parameters:
      type: hyperdisk-balanced
      provisioned-throughput-on-create: "250Mi"
      provisioned-iops-on-create: "7000"
    
  2. יוצרים את StorageClass:

    kubectl create -f hdb-example-class.yaml
    

Hyperdisk Throughput

  1. שומרים את המניפסט הבא בקובץ בשם hdt-example-class.yaml:

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: throughput-storage
    provisioner: pd.csi.storage.gke.io
    volumeBindingMode: WaitForFirstConsumer
    allowVolumeExpansion: true
    parameters:
      type: hyperdisk-throughput
      provisioned-throughput-on-create: "50Mi"
    
  2. יוצרים את StorageClass:

    kubectl create -f hdt-example-class.yaml
    

Hyperdisk Extreme

  1. שומרים את המניפסט הבא בקובץ בשם hdx-example-class.yaml:

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: extreme-storage
    provisioner: pd.csi.storage.gke.io
    volumeBindingMode: WaitForFirstConsumer
    allowVolumeExpansion: true
    parameters:
      type: hyperdisk-extreme
      provisioned-iops-on-create: "50000"
    
  2. יוצרים את StorageClass:

    kubectl create -f hdx-example-class.yaml
    

Hyperdisk Balanced HA

  1. שומרים את המניפסט הבא בקובץ בשם hdb-ha-example-class.yaml.

    • עבור אשכולות אזוריים, מגדירים את אזורי הזמינות שבהם רוצים ליצור את PersistentVolumes.

    • במקרים של אשכולות אזוריים, אפשר לבחור לא להגדיר את השדה allowedTopologies כדי ליצור את PersistentVolumes בשני אזורי זמינות שנבחרו באופן אקראי בזמן התזמון של ה-Pod.

    מידע נוסף על אזורים נתמכים זמין במאמר זמינות אזורית של Hyperdisk.

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: balanced-ha-storage
    provisioner: pd.csi.storage.gke.io
    volumeBindingMode: WaitForFirstConsumer
    allowVolumeExpansion: true
    parameters:
      type: hyperdisk-balanced-high-availability
      provisioned-throughput-on-create: "250Mi"
      provisioned-iops-on-create: "7000"
    allowedTopologies:
    - matchLabelExpressions:
      - key: topology.gke.io/zone
        values:
        - ZONE1
        - ZONE2
    
  2. יוצרים את StorageClass:

    kubectl create -f hdb-ha-example-class.yaml
    

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

kubectl get sc

יצירת PersistentVolumeClaim

אפשר ליצור PersistentVolumeClaim שמפנה ל-StorageClass של מנהל התקן CSI של Persistent Disk ב-Compute Engine.

Hyperdisk Balanced

בדוגמה הזו, מציינים את קיבולת האחסון המיועדת של נפח האחסון Hyperdisk Balanced כ-‎20 GiB.

  1. שומרים את מניפסט PersistentVolumeClaim הבא בקובץ בשם pvc-example.yaml:

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: podpvc
    spec:
      accessModes:
      - ReadWriteOnce
      storageClassName: balanced-storage
      resources:
        requests:
          storage: 20Gi
    
  2. מחילים את PersistentVolumeClaim שמפנה אל StorageClass שיצרתם מהדוגמה הקודמת:

    kubectl apply -f pvc-example.yaml
    

Hyperdisk Throughput

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

  1. שומרים את מניפסט PersistentVolumeClaim הבא בקובץ בשם pvc-example.yaml:

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: podpvc
    spec:
      accessModes:
      - ReadWriteOnce
      storageClassName: throughput-storage
      resources:
        requests:
          storage: 2Ti
    
  2. מחילים את PersistentVolumeClaim שמפנה אל StorageClass שיצרתם מהדוגמה הקודמת:

    kubectl apply -f pvc-example.yaml
    

Hyperdisk Extreme

בדוגמה הזו, מציינים את קיבולת האחסון המינימלית של נפח Hyperdisk Extreme כ-64 GiB.

  1. שומרים את מניפסט PersistentVolumeClaim הבא בקובץ בשם pvc-example.yaml:

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: podpvc
    spec:
      accessModes:
      - ReadWriteOnce
      storageClassName: extreme-storage
      resources:
        requests:
          storage: 64Gi
    
  2. מחילים את PersistentVolumeClaim שמפנה אל StorageClass שיצרתם מהדוגמה הקודמת:

    kubectl apply -f pvc-example.yaml
    

Hyperdisk Balanced HA

בדוגמה הזו, מציינים את קיבולת האחסון המינימלית של נפח האחסון של Hyperdisk Balanced High Availability כ-20 GiB ואת מצב הגישה כ-ReadWriteOnce. ‫Hyperdisk Balanced High Availability תומך גם במצבי גישה של ReadWriteMany ו-ReadWriteOncePod. במאמר מצבי גישה ל-Persistent Volume מוסבר על ההבדלים בין מצבי הגישה השונים ועל תרחישי השימוש בהם.

  1. שומרים את מניפסט PersistentVolumeClaim הבא בקובץ בשם pvc-example.yaml:

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: podpvc
    spec:
      accessModes:
      - ReadWriteOnce
      storageClassName: balanced-ha-storage
      resources:
        requests:
          storage: 20Gi
    
  2. מחילים את PersistentVolumeClaim שמפנה אל StorageClass שיצרתם מהדוגמה הקודמת:

    kubectl apply -f pvc-example.yaml
    

יצירת פריסה לשימוש בנפח Hyperdisk

כשמשתמשים ב-Pods עם PersistentVolumes, מומלץ להשתמש בבקר של עומס עבודה (למשל Deployment או StatefulSet).

  1. בדוגמה הבאה נוצר מניפסט שמגדיר Pod לפריסת שרת אינטרנט של Nginx באמצעות PersistentVolumeClaim שנוצר בקטע הקודם. שומרים את קובץ המניפסט לדוגמה הבא בשם hyperdisk-example-deployment.yaml:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: web-server-deployment
      labels:
        app: nginx
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - name: nginx
            image: nginx
            volumeMounts:
            - mountPath: /var/lib/www/html
              name: mypvc
          volumes:
          - name: mypvc
            persistentVolumeClaim:
              # Reference the PVC created earlier.
              claimName: podpvc
              readOnly: false
    
  2. כדי ליצור פריסה על סמך קובץ המניפסט hyperdisk-example-deployment.yaml, מריצים את הפקודה הבאה:

    kubectl apply -f hyperdisk-example-deployment.yaml
    
  3. מוודאים שהפריסה נוצרה בהצלחה:

    kubectl get deployment
    

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

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

    kubectl get pvc
    

הקצאת נפח אחסון מסוג Hyperdisk מתמונת מצב

כדי ליצור נפח Hyperdisk חדש מתמונת מצב קיימת של Persistent Disk, משתמשים במסוף Google Cloud , ב-Google Cloud CLI או ב-Compute Engine API. במאמר יצירה של תמונות מצב של נפחי אחסון ושימוש בהן מוסבר איך ליצור תמונת מצב של דיסק לאחסון מתמיד.

המסוף

  1. נכנסים לדף Disks במסוף Google Cloud .

    לפתיחת הדף Disks

  2. לוחצים על Create Disk.

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

    • Hyperdisk Balanced
    • Hyperdisk Extreme
    • Hyperdisk Throughput
    • Hyperdisk High Availability
  4. בקטע Disk source type (סוג המקור של הדיסק), לוחצים על Snapshot (קובץ snapshot).

  5. בוחרים את שם התמונה של הגיבוי שרוצים לשחזר.

  6. בוחרים את הגודל של הדיסק החדש ב-GiB. המספר הזה צריך להיות גדול או שווה לדיסק המקור המקורי של התמונה.

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

  8. לוחצים על Create כדי ליצור את נפח האחסון של Hyperdisk.

gcloud

מריצים את הפקודה gcloud compute disks create כדי ליצור את נפח האחסון של Hyperdisk מקובץ snapshot.

Hyperdisk Balanced

gcloud compute disks create DISK_NAME \
    --size=SIZE \
    --source-snapshot=SNAPSHOT_NAME \
    --provisioned-throughput=TRHROUGHPUT_LIMIT \
    --provisioned-iops=IOPS_LIMIT \
    --type=hyperdisk-balanced

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

  • DISK_NAME: השם של הדיסק החדש.
  • SIZE: הגודל של הדיסק החדש, בגיביבייט (GiB) או בטביבייט (TiB). מידע נוסף על מגבלות הקיבולת זמין במאמר בנושא מגבלות גודל וביצועים.
  • SNAPSHOT_NAME: השם של קובץ ה-snapshot שמשוחזר.
  • THROUGHPUT_LIMIT: אופציונלי. בדיסקים מסוג Hyperdisk Balanced, זהו מספר שלם שמייצג את קצב העברת הנתונים, שנמדד ב-MiB/s, שאליו הדיסק יכול להגיע. מידע נוסף על מגבלות הקיבולת זמין במאמר בנושא מגבלות גודל וביצועים.
  • IOPS_LIMIT: אופציונלי. בדיסקים מסוג Hyperdisk Balanced, זהו המספר המקסימלי של פעולות קלט/פלט בשנייה (IOPS) שהדיסק יכול להגיע אליו. מידע נוסף על מגבלות הקיבולת זמין במאמר בנושא מגבלות גודל וביצועים.

Hyperdisk Throughput

gcloud compute disks create DISK_NAME \
    --size=SIZE \
    --source-snapshot=SNAPSHOT_NAME \
    --provisioned-throughput=TRHROUGHPUT_LIMIT \
    --type=hyperdisk-throughput

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

  • DISK_NAME: השם של הדיסק החדש.
  • SIZE: הגודל של הדיסק החדש בגיביבייט (GiB או GB) או בטביבייט (TiB או TB). מידע נוסף על מגבלות הקיבולת זמין במאמר בנושא מגבלות גודל וביצועים.
  • SNAPSHOT_NAME: השם של קובץ ה-snapshot שמשוחזר.
  • THROUGHPUT_LIMIT: אופציונלי: בדיסקים מסוג Hyperdisk Throughput, זהו מספר שלם שמייצג את קצב העברת הנתונים, שנמדד ב-MiB/s, שאליו הדיסק יכול להגיע. מידע נוסף על מגבלות הקיבולת זמין במאמר בנושא מגבלות גודל וביצועים.

Hyperdisk Extreme

gcloud compute disks create DISK_NAME \
    --size=SIZE \
    --source-snapshot=SNAPSHOT_NAME \
    --provisioned-iops=IOPS_LIMIT \
    --type=hyperdisk-extreme

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

  • DISK_NAME: השם של הדיסק החדש.
  • SIZE: הגודל, בגיביבייט (GiB או GB) או בטביבייט (TiB או TB), של הדיסק החדש. מידע נוסף על מגבלות הקיבולת זמין במאמר בנושא מגבלות גודל וביצועים.
  • SNAPSHOT_NAME: השם של קובץ ה-snapshot שמשוחזר.
  • IOPS_LIMIT: אופציונלי: בדיסקים מסוג Hyperdisk Extreme, זהו המספר המקסימלי של פעולות קלט/פלט לשנייה שהדיסק יכול להגיע אליו. מידע נוסף על מגבלות הקיבולת זמין במאמר מגבלות הגודל והביצועים.

Hyperdisk Balanced HA

gcloud compute disks create DISK_NAME \
    --size=SIZE \
    --region=REGION \
    --replica-zones=('ZONE1', 'ZONE2') \
    --source-snapshot=SNAPSHOT_NAME \
    --provisioned-throughput=TRHROUGHPUT_LIMIT \
    --provisioned-iops=IOPS_LIMIT \
    --type=hyperdisk-balanced-high-availability

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

  • DISK_NAME: השם של הדיסק החדש.
  • SIZE: הגודל, בגיביבייט (GiB) או בטביבייט (TiB), של הדיסק החדש. במאמרי העזרה של Compute Engine מפורטים מגבלות הקיבולת העדכניות.
  • REGION: האזור של הדיסק החדש. למידע על הזמינות האזורית העדכנית, אפשר לעיין במאמרי העזרה של Compute Engine.
  • ZONE1, ZONE2: האזורים בתוך האזור שבו ימוקמו העותקים.
  • SNAPSHOT_NAME: השם של קובץ ה-snapshot שמשוחזר.
  • THROUGHPUT_LIMIT: אופציונלי. בדיסקים מסוג Hyperdisk Balanced High Availability, הערך הזה הוא מספר שלם שמייצג את קצב העברת הנתונים, שנמדד ב-MiB/s, שהדיסק יכול להגיע אליו. מידע נוסף על מגבלות הקיבולת זמין במאמר בנושא מגבלות גודל וביצועים.
  • IOPS_LIMIT: אופציונלי. בדיסקים מסוג Hyperdisk Balanced High Availability, זהו מספר ה-IOPS המקסימלי שהדיסק יכול להגיע אליו. מידע נוסף על מגבלות הקיבולת זמין במאמר בנושא מגבלות גודל וביצועים.

יצירת snapshot לנפח Hyperdisk

כדי ליצור snapshot מנפח Hyperdisk, פועלים לפי אותם השלבים שבהם יוצרים snapshot מנפח Persistent Disk:

עדכון של נפח התפוקה או של פעולות הקלט/פלט בשנייה (IOPS) של נפח Hyperdisk קיים

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

תפוקה

אפשר לעדכן את רוחב הפס שהוקצה רק לנפחי אחסון מסוג Hyperdisk Balanced, ‏ Hyperdisk Balanced High Availability ו-Hyperdisk Throughput.

כדי לעדכן את רמת התפוקה שהוקצתה לנפח Hyperdisk, צריך לפעול לפי ההוראות לשימוש במסוף, ב-ה-CLI של gcloud או ב-Compute Engine API במאמר שינוי הביצועים שהוקצו לנפח Hyperdisk. Google Cloud

אחרי שיוצרים נפח אחסון של Hyperdisk, אפשר לשנות את רמת התפוקה שהוקצתה (עד פעם אחת בכל 4 שעות). יכול להיות שיחלפו עד 15 דקות עד שהשינויים ברמות התפוקה ייכנסו לתוקף. במהלך שינוי הביצועים, כל הסכמי רמת השירות (SLA) והיעדים (SLO) שקשורים לביצועים לא תקפים. אפשר לשנות את רמת התפוקה של נפח אחסון קיים בכל שלב, בלי קשר לשאלה אם הדיסק מחובר למופע פעיל או לא.

רמת התפוקה החדשה שאתם מציינים צריכה להיות אחת מהערכים הנתמכים עבור נפחי Hyperdisk Balanced,‏ Hyperdisk Throughput ו-Hyperdisk Balanced High Availability, בהתאמה.

כדי לעדכן את רמת התפוקה שהוקצתה לנפח Hyperdisk, צריך לזהות את השם של ה-Persistent Disk שמשמש כבסיס למשאבי PersistentVolumeClaim ו-PersistentVolume:

  1. נכנסים אל חלונית האובייקטים במסוף Google Cloud .

    כניסה לדף Object Browser

  2. מחפשים את הרשומה של אובייקט PersistentVolumeClaim.

  3. לוחצים על הקישור נפח .

  4. פותחים את הכרטיסייה YAML של PersistentVolume המשויך. מחפשים את הערך של CSI volumeHandle בכרטיסייה הזו.

  5. שימו לב לאלמנט האחרון של ה-handle (הערך שלו צריך להיות כמו pvc-XXXXX). זה השם של PersistentVolumeClaim. חשוב גם לשים לב לפרויקט ולאזור.

IOPS

אפשר לעדכן את מספר ה-IOPS שהוקצה רק לנפחי אחסון מסוג Hyperdisk Balanced, ‏ Hyperdisk Balanced High Availability ו-Hyperdisk Extreme.

כדי לעדכן את רמת ה-IOPS שהוקצתה לנפח Hyperdisk, צריך לפעול לפי ההוראות לשימוש במסוף, ב-gcloud CLI או ב-Compute Engine API במאמר שינוי הביצועים שהוקצו לנפח Hyperdisk. Google Cloud

אחרי שיוצרים נפח אחסון של Hyperdisk IOPS, אפשר לשנות את רמת ה-IOPS שהוקצתה (עד פעם אחת בכל 4 שעות). יכול להיות שיחלפו עד 15 דקות לפני שרמות ה-IOPS החדשות ייכנסו לתוקף. במהלך שינוי הביצועים, כל הסכמי רמת השירות (SLA) והיעדים (SLO) שקשורים לביצועים לא תקפים. אפשר לשנות את רמת ה-IOPS של נפח אחסון קיים בכל שלב, בלי קשר לשאלה אם הדיסק מחובר למופע פעיל או לא.

רמת ה-IOPS החדשה שאתם מציינים צריכה להיות אחת מהרמות הנתמכות עבור נפחי Hyperdisk Balanced או Hyperdisk Extreme.

כדי לעדכן את רמת ה-IOPS שהוקצתה לנפח Hyperdisk, צריך לזהות את השם של ה-Persistent Disk שמגבה את משאבי PersistentVolumeClaim ו-PersistentVolume:

  1. נכנסים אל חלונית האובייקטים במסוף Google Cloud .

    כניסה לדף Object Browser

  2. מחפשים את הרשומה של אובייקט PersistentVolumeClaim.

  3. לוחצים על הקישור נפח .

  4. פותחים את הכרטיסייה YAML של PersistentVolume המשויך. מחפשים את הערך של CSI volumeHandle בכרטיסייה הזו.

  5. שימו לב לאלמנט האחרון של ה-handle (הערך שלו צריך להיות כמו pvc-XXXXX). זה השם של PersistentVolumeClaim. חשוב גם לשים לב לפרויקט ולאזור.

מעקב אחר קצב העברת הנתונים או IOPS בנפח אחסון מסוג Hyperdisk

כדי לעקוב אחר הביצועים של נפח ה-Hyperdisk שהוקצה, אפשר לעיין במאמר ניתוח של פעולות קלט/פלט בשנייה (IOPS) וקצב העברת נתונים שהוקצו במסמכי התיעוד של Compute Engine.

פתרון בעיות

בקטע הזה מפורטות הוראות לפתרון בעיות שקשורות לנפחי Hyperdisk ב-GKE.

אי אפשר לשנות את הביצועים או הקיבולת: היחס לא בטווח

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

  • Requested provisioned throughput cannot be higher than <value>.
  • Requested provisioned throughput cannot be lower than <value>.
  • Requested provisioned throughput is too high for the requested disk size.
  • Requested provisioned throughput is too low for the requested disk size.
  • Requested disk size is too high for current provisioned throughput.

התפוקה שהוקצתה לנפחי Hyperdisk Throughput חייבת לעמוד בדרישות הבאות:

  • לפחות ‎10 MiB/s לכל TiB של קיבולת, ולא יותר מ-‎90 MiB/s לכל TiB של קיבולת.
  • עד 600MiB/s לכל נפח אחסון.

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

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

השגיאה הבאה מתרחשת כשמנסים לשנות את רמת הביצועים שהוקצתה, אבל רמת הביצועים כבר שונתה ב-4 השעות האחרונות:

Cannot update provisioned throughput due to being rate limited.
Cannot update provisioned iops due to being rate limited.

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

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