Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

בדף הזה מוסבר איך אפשר להשתמש ב-GKE Hyperdisk Storage Pools כדי לאגד ולשתף את קיבולת האחסון, התפוקה ו-IOPS בין דיסקים באשכולות Google Kubernetes Engine‏ (GKE).

סקירה כללית

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מכסה

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

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

אפשר להשתמש במסנני המכסות הבאים עבור מאגרי אחסון מאוזנים של Hyperdisk:

‫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:

‫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 .

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

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

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

הפעלת 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.

יצירת מאגר אחסון של Hyperdisk

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

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

לדוגמה, השתמשו בפקודה הבאה כדי ליצור מאגר אחסון Hyperdisk Balanced עם קיבולת Advanced וביצועים Advanced, ולהקצות קיבולת של 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 .

בדיקת אזורים של מאגר אחסון

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

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

gcloud container clusters describe CLUSTER_NAME  | yq '.locations'

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

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

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

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

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

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

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,[...]: רשימה מופרדת בפסיקים של נתיבי משאבים של מאגר אחסון (לדוגמה, projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c) שבהם יוקצו דיסקים לאתחול של האשכול. מוודאים שהאזורים בנתיבי המשאבים של מאגר האחסון תואמים לאזורים ב---node-locations.
‫ZONE,[...]: רשימה מופרדת בפסיקים של אזורים שבהם צריך לשכפל את טביעת הרגל של הצומת. במקום זאת, אפשר לציין אזורים עבור אשכולות אזוריים. כל האזורים צריכים להיות באותו אזור שבו נמצא האשכול, כפי שמצוין בדגל --location.
‫MACHINE_TYPE: סוג המכונה הנתמך שרוצים להשתמש בו לצמתים.
‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.

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

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

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,[...]: רשימה מופרדת בפסיקים של נתיבי משאבים של מאגר אחסון (לדוגמה, projects/my-project/zones/us-east4-c/storagePools/pool-us-east4-c) שבהם יוקצו דיסקים לאתחול של האשכול. מוודאים שהאזורים בנתיבי המשאבים של מאגר האחסון תואמים לערכים ב---node-locations.
‫ZONE,[...]: רשימה מופרדת בפסיקים של אזורים שבהם צריך לשכפל את טביעת הרגל של הצומת. כל האזורים צריכים להיות באותו אזור כמו האשכול, שמוגדר באמצעות הדגל -location.
‫MACHINE_TYPE: סוג המכונה הנתמך שרוצים להשתמש בו לצמתים.
‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.
‫CLUSTER_NAME: אשכול קיים שבו יוצרים את מאגר הצמתים.

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

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

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

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

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

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

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

בקטע הזה:

יוצרים אשכול GKE חדש עם דיסקים מצורפים שהוקצו במאגר אחסון.
יוצרים StorageClass כדי להקצות באופן דינמי PersistentVolume (PV) כש-Pod מבקש אותו דרך PersistentVolumeClaim (PVC). כדי ש-PV יוכל לצרוך את המשאבים המשותפים של נפח האחסון הארגוני, צריך לציין את נפח האחסון הארגוני באמצעות הפרמטר 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 שזמינות עם סוג המחשוב 'ביצועים' מופיעה במאמר בנושא סדרות מכונות נתמכות.

רגילה

כדי ליצור אשכול אזורי רגיל באמצעות ה-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 בתוך מאגר אחסון, צריך להשתמש ב-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 Type	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 במאגר האחסון 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:

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. מידע נוסף זמין במאמר בנושא תמיכה בסוגי מכונות עבור Hyperdisks. בדוגמה הבאה של פריסה נעשה שימוש בסדרת מכונות c3.

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

טייס אוטומטי

בקטגוריות של Autopilot, מציינים את cloud.google.com/compute-class: Performance nodeSelector כדי להקצות נפח אחסון מאוזן של 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 של אמצעי האחסון ומוחקים את קובץ הבדיקה מהדיסק.
משחזרים את התמונה לדיסק חדש באותו מאגר אחסון, וכך משחזרים את הנתונים שנמחקו.

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

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

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

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

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

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

ה-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.
```
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

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

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

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

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

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

סקירה כללית

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

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

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

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

מכסה

תמחור

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

יצירת מאגר אחסון של Hyperdisk

בדיקת אזורים של מאגר אחסון

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

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

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

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

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

יצירת אשכול GKE

טייס אוטומטי

רגילה

יצירת StorageClass

יצירת PersistentVolumeClaim‏ (PVC)

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

טייס אוטומטי

רגילה

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

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

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

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

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

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

הסרת המשאבים

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

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

מחיקת מאגר האחסון Hyperdisk

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

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