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

מנהל ההתקן של ה-CSI של דיסקים לאחסון מתמיד ב-Compute Engine הוא הדרך העיקרית שלכם לגשת לאחסון 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 נדרשת גרסת GKE‏ 1.33 ואילך.
  • מוודאים שמנהל ה-CSI של דיסק מתמשך ב-Compute Engine מופעל. הדרייבר של דיסק מתמשך ב-Compute Engine מופעל כברירת מחדל באשכולות חדשים במצב Autopilot ובמצב Standard, ואי אפשר להשבית או לערוך אותו כשמשתמשים ב-Autopilot. אם אתם צריכים להפעיל את מנהל ההתקן של CSI של דיסק מתמיד ב-Compute Engine מהאשכול, תוכלו לעיין במאמר בנושא הפעלת מנהל ההתקן של CSI של דיסק מתמיד ב-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 משתמש בברירות המחדל של סוג הדיסק לפי קיבולת. הנחיות לגבי הערכים המותרים של קצב העברת הנתונים או IOPS זמינות במאמר תכנון רמת הביצועים של נפח Hyperdisk.

פרמטר סוג Hyperdisk 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.
‫* אם אתם צריכים אבטחה משופרת ומתכננים להשתמש בצמתים סודיים של Google Kubernetes Engine, כדאי ליצור מצב סודי ל-Hyperdisk Balanced, לעיין במגבלות נוספות של מצב סודי ל-Hyperdisk Balanced ולקרוא מידע נוסף על צמתים סודיים של Google Kubernetes Engine.

בדוגמאות הבאות אפשר לראות איך יוצרים 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 שמפנה ל-StorageClass של מנהל התקן CSI של דיסק מתמשך ב-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, משתמשים במסוף Cloud de Confiance , ב-Google Cloud CLI או ב-Compute Engine API. במאמר יצירה של תמונות מצב של נפחי אחסון ושימוש בהן מוסבר איך ליצור תמונת מצב של דיסק לאחסון מתמיד.

המסוף

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

    לפתיחת הדף 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. Cloud de Confiance

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

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

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

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

    כניסה לדף 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, צריך לפעול לפי ההוראות לשימוש במסוף, ב-CLI של gcloud או ב-Compute Engine API במאמר שינוי הביצועים שהוקצו לנפח Hyperdisk. Cloud de Confiance

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

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

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

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

    כניסה לדף Object Browser

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

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

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

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

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

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