‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

טייס אוטומטי רגילה

במאמר הזה מוסבר איך לשפר את הביצועים של אחסון ב-Google Kubernetes Engine ‏ (GKE) ולצמצם את העלויות ב-GKE באמצעות מאגרי אחסון של Hyperdisk.

כדי לבצע אופטימיזציה של הביצועים והעלויות של האחסון בעומסי עבודה עם שמירת מצב באשכולות GKE, מומלץ להשתמש ב-GKE Hyperdisk Storage Pools. המאגרים האלה מאפשרים לכם לשתף ביעילות את קיבולת האחסון, את קצב העברת הנתונים ואת פעולות הקלט/פלט בשנייה (IOPS) בין כמה נפחי Hyperdisk. התמיכה ב-Hyperdisk תלויה בסוגי המכונות של הצמתים. מידע נוסף זמין במאמר בנושא תמיכה בסדרות מכונות ב-Hyperdisk.

המסמך הזה מיועד למומחי אחסון שמבצעים פריסה של עומסי עבודה עם שמירת מצב ב-GKE. מידע נוסף על תפקידים נפוצים ועל משימות לדוגמה שאנחנו מתייחסים אליהן בתוכן של Google Cloud זמין במאמר תפקידים נפוצים של משתמשי GKE ומשימות.

סקירה כללית

מאגרי אחסון מקבצים באופן לוגי התקני אחסון פיזיים, ומאפשרים לכם לפלח את המשאבים. אתם יכולים להקצות Google Cloud Hyperdisks בתוך מאגרי האחסון האלה, וכך ליצור בעצם מאגרי אחסון של Hyperdisk. ‫Hyperdisk Storage Pools מציע קיבולת, תפוקה ו-IOPS שהוקצו מראש, ודיסקים באשכול GKE יכולים לחלוק אותם.

אתם יכולים להשתמש ב-Hyperdisk Storage Pools כדי לנהל את משאבי האחסון בצורה יעילה יותר וחסכונית יותר. כך תוכלו ליהנות מטכנולוגיות יעילות כמו ביטול כפילויות והקצאת אחסון לפי צורך (Thin Provisioning).

במדריך הזה, משתמשים באזור us-east4-c כדי ליצור את Hyperdisk Balanced Storage Pool ומשאבים אחרים.

שיקולים בתכנון

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

יצירה וניהול של מאגרי אחסון

הדרישות והמגבלות הבאות חלות:

כל המגבלות של Compute Engine Hyperdisk Storage Pools חלות.
כל המגבלות שחלות על יצירת דיסקים ב-Hyperdisk Storage Pool חלות גם כאן.
סוג ה-Hyperdisk Storage Pool שיוצרים קובע את סוגי הדיסקים שאפשר ליצור ב-Storage Pool. סוגי Hyperdisk Storage Pools

הקצאת דיסקים לאתחול במאגרי אחסון

הדרישות והמגבלות הבאות חלות:

אין תמיכה בהקצאת דיסקים לאתחול במאגרי אחסון במאגרי צמתים שמופעל בהם הקצאה אוטומטית של צמתים.
מוודאים שמיקומי הצמתים של האשכול ומיקומי הצמתים של מאגר הצמתים תואמים בדיוק לאזורים של מאגר האחסון.
מוודאים שסוג המכונה שמריץ את ה-Pod תומך בצירוף של Hyperdisk מסוג Balanced. אי אפשר להשתמש ב-Hyperdisk Throughput כבדיסק אתחול. מידע נוסף על תמיכה בסוגי מכונות של Hyperdisk
אפשר להקצות דיסקים לאתחול ב-Storage Pools רק ב-node pools שנוצרו או עודכנו באופן ידני.

הקצאת דיסק מצורף במאגרי אחסון

הדרישות והמגבלות הבאות חלות:

הגרסה המינימלית של GKE שנדרשת להקצאת דיסקים מצורפים ב-Storage Pools היא ‎1.29.2-gke.1035000 ואילך.
מוודאים שהדרייבר של CSI לדיסק לאחסון מתמיד ב-Compute Engine מופעל. הדרייבר של דיסק מתמשך ב-Compute Engine מופעל כברירת מחדל באשכולות חדשים במצב Autopilot ובמצב Standard, ואי אפשר להשבית או לערוך אותו באשכולות במצב Autopilot. הוראות להפעלת ה-Driver מופיעות במאמר בנושא הפעלת ה-CSI Driver של Persistent Disk ב-Compute Engine באשכול קיים.
מוודאים שמאגר האחסון נמצא לפחות באחד ממיקומי הצמתים של האשכול ובמיקומי הצמתים של מאגר הצמתים.
אפשר להקצות דיסקים מסוג Hyperdisk Throughput ו-Hyperdisk Balanced רק ב-Storage Pools. הסוג של הדיסק המצורף חייב להיות זהה לסוג של מאגר האחסון. מידע נוסף זמין במאמר בנושא סוגים של מאגרי אחסון של Hyperdisk.
ב-StorageClass, מותר להשתמש רק ב-Storage Pool אחד לכל אזור.
ב-StorageClass, כל מאגרי האחסון צריכים להיות מסוג Storage Pool.
צריך לוודא שסוג המכונה שמריץ את ה-Pod תומך בחיבור סוג הדיסק שבו אתם משתמשים מ-Storage Pool. מידע נוסף זמין במאמר תמיכה בסוגי מכונות של Hyperdisk.

מכסה

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

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

אפשר להשתמש במסנני המכסות הבאים ל-Hyperdisk Balanced Storage Pools:

‫HDB-STORAGE-POOL-TOTAL-ADVANCED-CAPACITY-per-project-region: כדי להגדיל את הקיבולת באמצעות הקצאת קיבולת מתקדמת.
‫HDB-STORAGE-POOL-TOTAL-ADVANCED-IOPS-per-project-region: כדי להגדיל את ה-IOPS באמצעות הקצאת ביצועים מתקדמת.
‫HDB-STORAGE-POOL-TOTAL-ADVANCED-THROUGHPUT-per-project-region: כדי להגדיל את קצב העברת הנתונים באמצעות הקצאת משאבים מתקדמת לשיפור הביצועים.
‫HDB-TOTAL-GB-per-project-region: להגדלת הקיבולת באמצעות הקצאת קיבולת רגילה.
‫HDB-TOTAL-IOPS-per-project-region: כדי להגדיל את ה-IOPS באמצעות הקצאת ביצועים רגילה.
‫HDB-TOTAL-THROUGHPUT-per-project-region: כדי להגדיל את קצב העברת הנתונים באמצעות הקצאת משאבים לביצועים רגילים.

אפשר להשתמש במסנני המכסות הבאים עבור Hyperdisk Throughput Storage Pools:

‫HDT-STORAGE-POOL-TOTAL-ADVANCED-CAPACITY-per-project-region: כדי להגדיל את הקיבולת באמצעות הקצאת קיבולת מתקדמת.
‫HDT-STORAGE-POOL-TOTAL-ADVANCED-THROUGHPUT-per-project-region: כדי להגדיל את קצב העברת הנתונים באמצעות הקצאת משאבים מתקדמת לשיפור הביצועים.
‫HDT-TOTAL-GB-per-project-region: להגדלת הקיבולת באמצעות הקצאת קיבולת רגילה.
‫HDT-TOTAL-THROUGHPUT-per-project-region: כדי להגדיל את קצב העברת הנתונים באמצעות הקצאת משאבים לביצועים רגילים.

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

hdb-storage-pool-total-advanced-capacity-per-project-region.

תמחור

פרטים על התמחור מופיעים במאמר תמחור של Hyperdisk Storage Pools .

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

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

מפעילים את ממשק Google Kubernetes Engine API.

הפעלת Google Kubernetes Engine API

כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז לאתחל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
הערה: אם כבר התקנתם את ה-CLI של gcloud, הקפידו להגדיר את compute/region המאפיין. אם אתם משתמשים בעיקר באשכולות אזוריים, עליכם להגדיר את compute/zone במקום זאת. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו השגיאה הבאה: One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

כדאי לעיין באזורים ובאזורי זמינות נתמכים ליצירת Hyperdisk Balanced Storage Pool.

יצירת Hyperdisk Storage Pool

צריך ליצור Hyperdisk Storage Pool לפני שמקצים דיסקים לאתחול או דיסקים מצורפים ב-Storage Pool הזה. מידע נוסף זמין במאמר בנושא יצירת מאגרי אחסון של Hyperdisk.

חשוב לוודא שאתם יוצרים מאגרי אחסון באחד מהאזורים הנתמכים.

לדוגמה, משתמשים בפקודה הבאה כדי ליצור Hyperdisk Balanced Storage Pool עם קיבולת מתקדמת וביצועים מתקדמים, ולהקצות קיבולת של 10TB,‏ 10,000 IOPS/s וקצב העברת נתונים של 1,024MBps באזור us-east4-c:

export PROJECT_ID=PROJECT_ID
export ZONE=us-east4-c
gcloud compute storage-pools create pool-$ZONE \
  --provisioned-capacity=10tb --storage-pool-type=hyperdisk-balanced \
  --zone=$ZONE --project=$PROJECT_ID --capacity-provisioning-type=advanced \
  --performance-provisioning-type=advanced --provisioned-iops=10000 \
  --provisioned-throughput=1024

מחליפים את PROJECT_ID במזהה הפרויקט של Google Cloud החשבון.

בדיקת אזורים של Storage Pool

באשכולות במצב Autopilot ובאשכולות רגילים שבהם מופעלת הקצאת צמתים אוטומטית (NAP), אפשר ליצור Storage Pool בכל תחום (zone) באזור של האשכול. אם אין מאגר צמתים באזור שבו יצרתם את Storage Pool, ה-Pods יישארו במצב Pending עד שמנגנון שינוי הגודל האוטומטי של אשכול GKE יוכל להקצות מאגר צמתים חדש באזור הזה.
באשכולות Standard ללא הקצאת צמתים אוטומטית (NAP), צריך ליצור Storage Pools באזורי הצמתים שמוגדרים כברירת מחדל באשכול, כי Storage Pools הם משאבים של תחום מוגדר. אפשר להגדיר את אזורי הצמתים של האשכול באמצעות הדגל --node-locations.
- במקרה של אשכולות אזוריים, אם לא מציינים את --node-locations, כל הצמתים נוצרים באזור הראשי של האשכול.
- במקרה של אשכולות אזוריים, אם לא מציינים את --node-locations, ‏ GKE מפזר את צמתי העובדים בשלושה אזורים שנבחרו באופן אקראי בתוך האזור.

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

gcloud container clusters describe CLUSTER_NAME | yq '.locations'

מחליפים את CLUSTER_NAME בשם של האשכול שיוצרים בזמן הקצאת דיסק אתחול או דיסק מצורף.

הקצאת דיסק אתחול של GKE ב-Hyperdisk Storage Pool

אתם יכולים להקצות דיסק אתחול של GKE ב-Hyperdisk Storage Pool כשאתם מבצעים את הפעולות הבאות:

כשיוצרים אשכול GKE חדש
כשיוצרים מאגר צמתים חדש
כשמעדכנים מאגר צמתים קיים

כשיוצרים אשכול

כדי ליצור אשכול GKE עם דיסקים לאתחול שהוקצו ב-Storage Pool, משתמשים בפקודה הבאה:

gcloud container clusters create CLUSTER_NAME \
  --disk-type=DISK_TYPE --storage-pools=STORAGE_POOL,[...] \
  --node-locations=ZONE,[...] --machine-type=MACHINE_TYPE \
  --location=CONTROL_PLANE_LOCATION

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

‫CLUSTER_NAME: צריך לספק שם ייחודי לאשכול שיוצרים.
‫DISK_TYPE: מגדירים את הערך הזה ל-hyperdisk-balanced. אם לא מציינים ערך, סוג הדיסק מוגדר כברירת מחדל ל-Hyperdisk Balanced.
‫STORAGE_POOL,[...]: רשימה מופרדת בפסיקים של נתיבי משאבים של Storage Pool (לדוגמה, projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c) שבהם יוקצו דיסקי האתחול של האשכול. מוודאים שהאזורים בנתיבי המשאבים של Storage Pool תואמים לאזורים ב---node-locations.
‫ZONE,[...]: רשימה מופרדת בפסיקים של אזורים שבהם צריך לשכפל את טביעת הרגל של הצומת. במקום זאת, אפשר לציין אזורים עבור אשכולות אזוריים. כל האזורים צריכים להיות באותו אזור כמו האשכול, כפי שמצוין בדגל --location.
‫MACHINE_TYPE: סוג המכונה הנתמך שרוצים להשתמש בו לצמתים.
‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.

כשיוצרים מאגר צמתים

כדי ליצור מאגר צמתים של GKE עם דיסקים לאתחול שמוקצים ב-Storage Pool, משתמשים בפקודה הבאה:

gcloud container node-pools create NODE_POOL_NAME \
  --disk-type=DISK_TYPE --storage-pools=STORAGE_POOL,[...] \
  --node-locations=ZONE,[...] --machine-type=MACHINE_TYPE \
  --location=CONTROL_PLANE_LOCATION --cluster=CLUSTER_NAME

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

‫NODE_POOL_NAME: מציינים שם ייחודי למאגר הצמתים שיוצרים.
‫DISK_TYPE: מגדירים את הערך הזה ל-hyperdisk-balanced. אם לא מציינים ערך, סוג הדיסק מוגדר כברירת מחדל ל-Hyperdisk Balanced.
‫STORAGE_POOL,[...]: רשימה מופרדת בפסיקים של נתיבי משאבים של Storage Pool (לדוגמה, projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c) שבהם יוקצו דיסקי האתחול של האשכול. מוודאים שהאזורים בנתיבי המשאבים של Storage Pool תואמים לערכים ב---node-locations.
‫ZONE,[...]: רשימה מופרדת בפסיקים של אזורים שבהם צריך לשכפל את טביעת הרגל של הצומת. כל האזורים צריכים להיות באותו אזור כמו האשכול, שמוגדר באמצעות הדגל -location.
‫MACHINE_TYPE: סוג המכונה הנתמך שרוצים להשתמש בו לצמתים.
‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.
‫CLUSTER_NAME: אשכול קיים שבו יוצרים את מאגר הצמתים.

כשמעדכנים מאגר צמתים

אפשר להשתמש בפקודה update כדי להוסיף מאגרי אחסון או להחליף אותם במאגר צמתים. אי אפשר להשתמש בפקודה הזו כדי להסיר מאגרי אחסון ממאגר צמתים.

כדי לעדכן מאגר צמתים של GKE כך שדיסקי האתחול שלו יוקצו ב-Storage Pool, משתמשים בפקודה הבאה.

gcloud container node-pools update NODE_POOL_NAME \
 --storage-pools=STORAGE_POOL,[...] \
 --location=CONTROL_PLANE_LOCATION --cluster=CLUSTER_NAME

‫NODE_POOL_NAME: השם של מאגר צמתים קיים שרוצים לעדכן כדי להשתמש ב-Storage Pool.
‫STORAGE_POOL,[...]: רשימה מופרדת בפסיקים של נתיבי משאבים קיימים של Storage Pool (לדוגמה, projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c). חשוב לוודא שהאזורים בנתיבי המשאבים של Storage Pool תואמים לאזור של מאגר הצמתים שאתם מעדכנים.
‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.
‫CLUSTER_NAME: השם של אשכול GKE שאליו שייך מאגר הצמתים הזה.

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

הקצאת דיסק מצורף ל-GKE ב-Hyperdisk Storage Pool

בקטע הזה:

יוצרים אשכול GKE חדש עם דיסקים מצורפים שהוקצו ב-Storage Pool.
יוצרים StorageClass להקצאה דינמית של PersistentVolume (PV) כש-Pod מבקש אותו דרך PersistentVolumeClaim (PVC). כדי ש-PV ינצל את המשאבים המשותפים של Storage Pool, צריך לציין את Storage Pool באמצעות הפרמטר storage-pools ב-StorageClass. לאחר מכן, נעשה שימוש ב-StorageClass ב-PVC כדי להקצות את נפח האחסון המאוזן של Hyperdisk שבו ישתמש ה-Pod.
יוצרים PVC כדי לבקש PV – חלק מאחסון Hyperdisk – עבור Pod מאשכול GKE. כך תוכלו ליהנות מהמשאבים המשותפים של מאגר האחסון.
יוצרים Deployment שמשתמש ב-PVC כדי לוודא שלאפליקציה יש גישה לאחסון מתמיד גם אחרי הפעלה מחדש של Pod ותזמון מחדש.

יצירת אשכול GKE

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

טייס אוטומטי

כדי ליצור אשכול Autopilot באמצעות ה-CLI של gcloud, אפשר לעיין במאמר בנושא יצירת אשכול Autopilot.

דוגמה:

gcloud container clusters create-auto CLUSTER_NAME --location=CONTROL_PLANE_LOCATION

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

‫CLUSTER_NAME: מציינים שם ייחודי לאשכול שיוצרים.
‫CONTROL_PLANE_LOCATION: האזור ב-Compute Engine של מישור הבקרה של האשכול.

כדי לבחור סוג מכונה נתמך, מציינים את cloud.google.com/compute-class: PerformancenodeSelector בזמן יצירת פריסה. רשימת סדרות המכונות של Compute Engine שזמינות עם סוג המחשוב 'ביצועים' מופיעה במאמר בנושא סדרות מכונות נתמכות.

רגילה

כדי ליצור אשכול אזורי רגיל באמצעות gcloud CLI, אפשר לעיין במאמר בנושא יצירת אשכול אזורי.

כדי ליצור אשכול אזורי רגיל באמצעות ה-CLI של gcloud, אפשר לעיין במאמר בנושא יצירת אשכול אזורי.

דוגמה:

gcloud container clusters create CLUSTER_NAME --location=CONTROL_PLANE_LOCATION --project=PROJECT_ID --machine-type=MACHINE_TYPE --disk-type="DISK_TYPE"

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

‫CLUSTER_NAME: מזינים שם ייחודי לאשכול שיוצרים.
‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.
‫PROJECT_ID: מזהה הפרויקט של חשבון Google Cloud .
‫MACHINE_TYPE: סוג המכונה הנתמך שרוצים להשתמש בו לצמתים.
‫DISK_TYPE: מגדירים את הערך הזה ל-hyperdisk-balanced. אם לא מציינים ערך, סוג הדיסק מוגדר כברירת מחדל ל-Hyperdisk Balanced.

יצירת StorageClass

ב-Kubernetes, כדי לציין שרוצים ליצור את ה-PV בתוך Storage Pool, צריך להשתמש ב-StorageClass. מידע נוסף זמין במאמר בנושא StorageClasses.

כדי ליצור StorageClass חדש עם רמת התפוקה או ה-IOPS הרצויה:

משתמשים ב-pd.csi.storage.gke.io בשדה של כלי ההקצאה.
מציינים את סוג האחסון Hyperdisk Balanced.
מציינים את הפרמטר storage-pools עם ערך כרשימה של מאגרי אחסון ספציפיים שרוצים להשתמש בהם. כל מאגר אחסון ברשימה צריך להיות בפורמט: projects/PROJECT_ID/zones/ZONE/storagePools/STORAGE_POOL_NAME.
אופציונלי: מציינים את פרמטרי הביצועים provisioned-throughput-on-create ו-provisioned-iops-on-create.

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

פרמטר	סוג Hyperdisk	Usage
`provisioned-throughput-on-create`	Hyperdisk Balanced, Hyperdisk Throughput	מציינים את ערך התפוקה ב-MiB/s באמצעות המאפיין Mi. לדוגמה, אם התפוקה הנדרשת היא 250 MiB/s, מציינים `"250Mi"` כשיוצרים את StorageClass.
`provisioned-iops-on-create`	Hyperdisk Balanced, Hyperdisk IOPS	ערך ה-IOPS צריך להיות ללא תוספות. לדוגמה, אם אתם צריכים 7,000 IOPS, צריך לציין `"7000"` כשיוצרים את StorageClass.

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

כדי ליצור וליישם StorageClass בשם storage-pools-sc לאספקת PV באופן דינמי ב-Storage Pool projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c, משתמשים במניפסט הבא:

kubectl apply -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: storage-pools-sc
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
 type: hyperdisk-balanced
 provisioned-throughput-on-create: "140Mi"
 provisioned-iops-on-create: "3000"
 storage-pools: projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c
EOF

אם משתמשים ב-volumeBindingMode: WaitForFirstConsumer ב-StorageClass הזה, הקישור וההקצאה של PVC מתעכבים עד שנוצר Pod שמשתמש ב-PVC. הגישה הזו עוזרת לוודא שה-PV לא מוקצה מוקדם מדי, ושיש התאמה בין האזור של ה-PV לבין הפוד שמשתמש בו. אם האזורים לא תואמים, ה-Pod נשאר במצב Pending.

יצירת PersistentVolumeClaim‏ (PVC)

יוצרים PVC שמפנה אל StorageClass‏ storage-pools-sc שיצרתם.

משתמשים במניפסט הבא כדי ליצור PVC בשם my-pvc, עם 2,048 GiB כקיבולת האחסון של יעד הנפח Hyperdisk Balanced:

kubectl apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: my-pvc
spec:
 storageClassName: storage-pools-sc
 accessModes:
 - ReadWriteOnce
 resources:
  requests:
   storage: 2048Gi
EOF

יצירת פריסה שמשתמשת ב-PVC

שיטה מומלצת:

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

כדי לוודא שאפשר לתזמן Pods במאגר צמתים עם סדרת מכונות שתומכת ב-Hyperdisk Balanced, צריך להגדיר Deployment עם cloud.google.com/machine-familynode selector. מידע נוסף זמין במאמר בנושא תמיכה בסוגי מכונות עבור Hyperdisk. בדוגמה הבאה של פריסה נעשה שימוש בסדרת מכונות c3.

יוצרים את קובץ המניפסט הבא ומחילים אותו כדי להגדיר Pod לפריסת שרת אינטרנט של Postgres באמצעות ה-PVC שנוצר בקטע הקודם:

טייס אוטומטי

ב-Autopilot clusters, מציינים את cloud.google.com/compute-class: PerformancenodeSelector כדי להקצות נפח אחסון מאוזן של Hyperdisk. מידע נוסף זמין במאמר בנושא שליחת בקשה לצומת ייעודי עבור Pod.

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
 name: postgres
spec:
 selector:
  matchLabels:
   app: postgres
 template:
  metadata:
   labels:
    app: postgres
  spec:
   nodeSelector:
    cloud.google.com/machine-family: c3
    cloud.google.com/compute-class: Performance
   containers:
   - name: postgres
    image: postgres:14-alpine
    args: [ "sleep", "3600" ]
    volumeMounts:
    - name: sdk-volume
     mountPath: /usr/share/data/
   volumes:
   - name: sdk-volume
    persistentVolumeClaim:
     claimName: my-pvc
EOF

רגילה

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

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
 name: postgres
spec:
 selector:
  matchLabels:
   app: postgres
 template:
  metadata:
   labels:
    app: postgres
  spec:
   nodeSelector:
    cloud.google.com/machine-family: c3
   containers:
   - name: postgres
    image: postgres:14-alpine
    args: [ "sleep", "3600" ]
    volumeMounts:
    - name: sdk-volume
     mountPath: /usr/share/data/
   volumes:
   - name: sdk-volume
    persistentVolumeClaim:
     claimName: my-pvc
EOF

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

 kubectl get deployment

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

בדיקה אם הוקצה נפח אחסון לדיסק המצורף

בודקים אם ה-PVC בשם my-pvc נקשר בהצלחה ל-PV:

kubectl get pvc my-pvc

הפלט אמור להיראות כך:


NAME     STATUS  VOLUME                   CAPACITY  ACCESS MODES  STORAGECLASS    AGE
my-pvc    Bound  pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6  2Ti    RWO      storage-pools-sc  2m24s

בודקים אם נפח האחסון הוקצה כמו שצוין ב-StorageClass וב-PVC:

gcloud compute storage-pools list-disks pool-us-east4-c --zone=us-east4-c

הפלט אמור להיראות כך:

NAME                   STATUS PROVISIONED_IOPS PROVISIONED_THROUGHPUT SIZE_GB
pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6 READY  3000       140           2048

יצירת תמונת מצב ושחזור של דיסקים מצורפים ב-Storage Pools

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

בקטע הזה:

כותבים קובץ בדיקה לדיסק שהוקצה ב-Pod.
יוצרים קובץ snapshot של אמצעי האחסון ומוחקים את קובץ הבדיקה מהדיסק.
משחזרים את ה-snapshot לדיסק חדש באותו Storage Pool, וכך משחזרים את הנתונים שנמחקו.

יצירת קובץ בדיקה

כדי ליצור ולאמת קובץ בדיקה:

אחזור שם ה-Pod של פריסת Postgres:

kubectl get pods -l app=postgres

הפלט אמור להיראות כך:

NAME             READY  STATUS  RESTARTS  AGE
postgres-78fc84c9ff-77vx6  1/1   Running  0     44s

יוצרים קובץ בדיקה hello.txt ב-Pod:

kubectl exec postgres-78fc84c9ff-77vx6 \
 -- sh -c 'echo "Hello World!" > /usr/share/data/hello.txt'

מוודאים שקובץ הבדיקה נוצר:

kubectl exec postgres-78fc84c9ff-77vx6 \
 -- sh -c 'cat /usr/share/data/hello.txt'
Hello World!

יצירת snapshot של נפח ומחיקת קובץ בדיקה

כדי ליצור ולאמת snapshot:

יוצרים VolumeSnapshotClass שמציין איך צריך לצלם ולנהל את תמונת המצב של אמצעי האחסון:

kubectl apply -f - <<EOF
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
 name: my-snapshotclass
driver: pd.csi.storage.gke.io
deletionPolicy: Delete
EOF

יוצרים VolumeSnapshot ומצלמים את ה-snapshot מהנפח שמקושר ל-my-pvc PersistentVolumeClaim:

kubectl apply -f - <<EOF
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
 name: my-snapshot
spec:
 volumeSnapshotClassName: my-snapshotclass
 source:
  persistentVolumeClaimName: my-pvc
EOF

מוודאים שנוצר תוכן של ה-snapshot של אמצעי האחסון:

kubectl get volumesnapshotcontents

הפלט אמור להיראות כך:

NAME                        READYTOUSE  RESTORESIZE   DELETIONPOLICY  DRIVER         VOLUMESNAPSHOTCLASS  VOLUMESNAPSHOT  VOLUMESNAPSHOTNAMESPACE  AGE
snapcontent-e778fde2-5f1c-4a42-a43d-7f9d41d093da  false    2199023255552  Delete      pd.csi.storage.gke.io  my-snapshotclass   my-snapshot   default          33s

מוודאים שקובץ ה-snapshot מוכן לשימוש:

kubectl get volumesnapshot \
 -o custom-columns='NAME:.metadata.name,READY:.status.readyToUse'

הפלט אמור להיראות כך:

NAME     READY
my-snapshot  true

מוחקים את קובץ הבדיקה המקורי hello.txt שנוצר ב-Pod postgres-78fc84c9ff-77vx6:
```
kubectl exec postgres-78fc84c9ff-77vx6 \
  -- sh -c 'rm /usr/share/data/hello.txt'
```

שחזור תמונת המצב של עוצמת הקול

כדי לשחזר את תמונת המצב של עוצמת הקול והנתונים:

יוצרים PVC חדש שמשחזר נתונים מתמונת מצב, ומוודאים שהנפח החדש מוקצה באותו מאגר אחסון (storage-pools-sc) כמו הנפח המקורי. מחילים את המניפסט הבא:

kubectl apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: pvc-restore
spec:
 dataSource:
  name: my-snapshot
  kind: VolumeSnapshot
  apiGroup: snapshot.storage.k8s.io
 storageClassName: storage-pools-sc
 accessModes:
  - ReadWriteOnce
 resources:
  requests:
   storage: 2048Gi
EOF

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

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
 name: postgres
spec:
 selector:
  matchLabels:
   app: postgres
 template:
  metadata:
   labels:
    app: postgres
  spec:
   nodeSelector:
    cloud.google.com/machine-family: c3
   containers:
   - name: postgres
    image: google/cloud-sdk:slim
    args: [ "sleep", "3600" ]
    volumeMounts:
    - name: sdk-volume
     mountPath: /usr/share/data/
   volumes:
   - name: sdk-volume
    persistentVolumeClaim:
     claimName: pvc-restore
EOF

מקבלים את השם של ה-Pod החדש שנוצר כחלק מ-postgres Deployment:

kubectl get pods -l app=postgres

הפלט אמור להיראות כך:

NAME             READY  STATUS    RESTARTS  AGE
postgres-59f89cfd8c-42qtj  1/1   Running    0     40s

מוודאים שקובץ hello.txt, שנמחק קודם, נמצא עכשיו ב-Pod החדש (postgres-59f89cfd8c-42qtj) אחרי שחזור הנפח מתמונת המצב:
```
kubectl exec postgres-59f89cfd8c-42qtj \
 -- sh -c 'cat /usr/share/data/hello.txt'
Hello World!
```
כך מוודאים שתהליך יצירת תמונת המצב והשחזור הושלם בהצלחה, ושהנתונים מתמונת המצב שוחזרו ל-PV החדש שאליו יש גישה ל-Pod.

מוודאים שהנפח שנוצר מקובץ ה-snapshot נמצא במאגר האחסון:

kubectl get pvc pvc-restore

הפלט אמור להיראות כך:

NAME     STATUS  VOLUME                   CAPACITY  ACCESS MODES  STORAGECLASS    AGE
pvc-restore  Bound  pvc-b287c387-bc51-4100-a00e-b5241d411c82  2Ti    RWO      storage-pools-sc  2m24s

בודקים אם הנפח החדש הוקצה כמו שצוין ב-StorageClass וב-PVC:

gcloud compute storage-pools list-disks pool-us-east4-c --zone=us-east4-c

הפלט אמור להיראות כך, עם נפח האחסון החדש pvc-b287c387-bc51-4100-a00e-b5241d411c82 שהוקצה באותו מאגר אחסון.


NAME                   STATUS PROVISIONED_IOPS PROVISIONED_THROUGHPUT SIZE_GB
pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6 READY  3000       140           2048
pvc-b287c387-bc51-4100-a00e-b5241d411c82 READY  3000       140           2048

ההגדרה הזו עוזרת לוודא שהנפח המשוחזר נהנה מהמשאבים והיכולות המשותפים של המאגר.

העברה של נפחי אחסון קיימים למאגר אחסון

אפשר להשתמש בצילום מצב ובשחזור כדי להעביר נפחי אחסון שנמצאים מחוץ ל-Storage Pool אל Storage Pool.

ודאו שהתנאים הבאים מתקיימים:

ה-PVC החדש pvc-restore מפנה אל StorageClass שמציין את הפרמטר storage-pools, ומצביע על מאגר האחסון שאליו רוצים להעביר את הווליום.
ה-PV של המקור שנוצרת ממנו תמונת המצב צריך להיות משויך ל-PVC עם StorageClass שלא מצוין בו הפרמטר storage-pools.

אחרי שמשחזרים מתמונת מצב לנפח חדש, אפשר למחוק את ה-PVC ואת ה-PV של המקור.

הסרת המשאבים

כדי להימנע מחיובים בחשבון Google Cloud , מוחקים את משאבי האחסון שיצרתם במדריך הזה. קודם מוחקים את כל הדיסקים ב-Storage Pool ואז מוחקים את ה-Storage Pool.

מחיקת דיסק האתחול

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

למידע נוסף:

מחיקת הדיסק המצורף

כדי למחוק את הדיסק המצורף שהוקצה במאגר אחסון של Hyperdisk:

מוחקים את ה-Pod שמשתמש ב-PVC:
```
kubectl delete deployments postgres
```
מוחקים את ה-PVC שמשתמש ב-StorageClass של Hyperdisk Storage Pool.
```
kubectl delete pvc my-pvc
```
מוודאים ש-PVC pvc-1ff52479-4c81-4481-aa1d-b21c8f8860c6 נמחק:
```
gcloud compute storage-pools list-disks pool-us-east4-c --zone=us-east4-c
```

מחיקת Hyperdisk Storage Pool

מוחקים את Hyperdisk Storage Pool באמצעות הפקודה הבאה:

gcloud compute storage-pools delete pool-us-east4-c --zone=us-east4-c --project=my-project

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

אפשר לעיין במאמר בנושא פתרון בעיות באחסון ב-GKE.
מידע נוסף על מנהל התקן Persistent Disk CSI ב-GitHub

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

סקירה כללית

שיקולים בתכנון

יצירה וניהול של מאגרי אחסון

הקצאת דיסקים לאתחול במאגרי אחסון

הקצאת דיסק מצורף במאגרי אחסון

מכסה

תמחור

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

יצירת Hyperdisk Storage Pool

בדיקת אזורים של Storage Pool

הקצאת דיסק אתחול של GKE ב-Hyperdisk Storage Pool

כשיוצרים אשכול

כשיוצרים מאגר צמתים

כשמעדכנים מאגר צמתים

הקצאת דיסק מצורף ל-GKE ב-Hyperdisk Storage Pool

יצירת אשכול GKE

טייס אוטומטי

רגילה

יצירת StorageClass

יצירת PersistentVolumeClaim‏ (PVC)

יצירת פריסה שמשתמשת ב-PVC

טייס אוטומטי

רגילה

בדיקה אם הוקצה נפח אחסון לדיסק המצורף

יצירת תמונת מצב ושחזור של דיסקים מצורפים ב-Storage Pools

יצירת קובץ בדיקה

יצירת snapshot של נפח ומחיקת קובץ בדיקה

שחזור תמונת המצב של עוצמת הקול

העברה של נפחי אחסון קיימים למאגר אחסון

הסרת המשאבים

מחיקת דיסק האתחול

מחיקת הדיסק המצורף

מחיקת Hyperdisk Storage Pool

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

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