סקירה כללית על אחסון באשכולות GKE

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

‫GKE תומך בסוגי האחסון ובשילובים הבאים:

אחסון בלוקים (דיסק אחסון מתמיד)

נפחי אחסון של דיסקים לאחסון מתמיד (persistent disk) הם מכשירים עמידים לאחסון ברשת שמנוהלים על ידי Compute Engine, ולאשכולות GKE יש גישה אליהם כמו לדיסקים פיזיים במחשב או בשרת. אם נדרש נפח אחסון נוסף לאשכולות, אפשר לצרף עוד נפחי אחסון של Persistent Disk לצמתים או לשנות את הגודל של נפחי האחסון הקיימים של Persistent Disk. אתם יכולים לאפשר ל-GKE להקצות באופן דינמי PersistentVolumes שמגובים על ידי Persistent Disk, או להקצות דיסקים באופן ידני.

אפשרות האחסון הזו נתמכת באשכולות GKE Autopilot ו-Standard.

כברירת מחדל, נפחי אחסון של דיסקים לאחסון מתמיד הם משאבים של תחום מוגדר (נשמרים בתחום אחד באזור). אתם יכולים ליצור נפחי אחסון מתמיד (Persistent Disk) אזוריים (שנשמרים בשני אזורים באותו אזור). אפשר גם לצרף נפח של Persistent Disk במצב קריאה בלבד לכמה צמתים בו-זמנית. התכונה הזו נתמכת גם בנפחי Persistent Disk אזוריים וגם בנפחי Persistent Disk של תחום מוגדר.

אחסון ב-Persistent Disk ב-GKE הוא מתמשך, כלומר הנתונים שמאוחסנים בדיסקים יישארו גם אם ה-Pod שמשתמש בהם יופסק.

למה כדאי להשתמש באחסון מסוג Persistent Disk

משתמשים באחסון מסוג Persistent Disk אם נדרשת גישה לאחסון בלוקים (block storage) עמיד, בעל זמינות גבוהה וביצועים גבוהים. נפח של אחסון מתמיד (Persistent Disk) מחובר בדרך כלל ל-Pod יחיד. אפשרות האחסון הזו תומכת במצב הגישה ReadWriteOnce. ‫GKE תומך בהגדרת נפחי אחסון של Persistent Disk עם מגוון אפשרויות של זמן אחזור וביצועים, כולל האפשרויות הבאות:

  • דיסק אחסון מתמיד מאוזן: מתאים לאפליקציות ארגוניות רגילות. האפשרות הזו מאפשרת לכם לאזן בין ביצועים לעלות. מגובה בכונני SSD. זו אפשרות ברירת המחדל להקצאת נפח דינמית באשכולות ובצמתים שמופעלת בהם GKE מגרסה 1.24 ואילך.
  • דיסק קשיח לביצועים מתמשכים: מתאים לניתוח נתונים בהרחבת קנה מידה, למסדי נתונים ולשמירת נתונים במטמון באופן קבוע. האפשרות הזו מתאימה לעומסי עבודה שבהם הביצועים חשובים. מגובה בכונני SSD.
  • ‫דיסק מתמיד סטנדרטי: מתאים לעומסי עבודה של נתונים גדולים ושל מחשוב גדול. האפשרות הזו היא סוג הדיסק הכי חסכוני. מגובה על ידי כוננים קשיחים (HDD) רגילים.
  • אחסון מתמיד (persistent disk) קיצוני: מתאים לאפליקציות ארגוניות כמו SAP HANA ו-Oracle. האפשרות הזו מציעה את הביצועים הכי טובים כדי לענות על הצרכים של מסדי הנתונים הגדולים ביותר בזיכרון. מגובה בכונני SSD. באפליקציות שבהן הביצועים הם קריטיים, ואחסון מתמיד (persistent disk) לא מספק ביצועים מספיקים, כדאי להשתמש בדיסקים של Hyperdisk Extreme.

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

אחסון בלוקים (Google Cloud Hyperdisk)

נפחי Hyperdisk משתמשים בדור הבא של Cloud de Confiance אחסון בלוקים. נפחי Hyperdisk מאפשרים לכם לכוונן באופן דינמי את הביצועים של אחסון הבלוקים בהתאם לעומס העבודה. אתם יכולים להגדיר את פעולות הקלט/פלט בשנייה (IOPS) ואת קצב העברת הנתונים בנפרד עבור האפליקציות שלכם, ולהתאים אותם לצרכים המשתנים של הביצועים לאורך זמן.

אפשרות האחסון הזו נתמכת באשכולות GKE Autopilot ו-Standard. נפחי Hyperdisk הם משאבים אזוריים, והם כפופים לזמינות אזורית. אחסון Hyperdisk ב-GKE הוא קבוע, כלומר הנתונים שמאוחסנים בדיסקים יישארו גם אם ה-Pod שמשתמש בהם יופסק.

למה כדאי להשתמש ב-Hyperdisk

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

  • ‫Hyperdisk Balanced: האפשרות הכי מתאימה לרוב עומסי העבודה. זו אפשרות טובה לפריסת רוב האפליקציות הארגוניות והעסקיות, וגם מסדי נתונים ושרתי אינטרנט.
  • ‫Hyperdisk Throughput: אופטימיזציה לשיפור העלות והתפוקה. זו אפשרות טובה אם תרחיש השימוש שלכם מכוון לניתוח נתונים בהרחבת קנה מידה (לדוגמה, Hadoop או Kafka), לשחזור נתונים לא פעילים משרתי גיבוי ולעומסי עבודה רגישים לעלויות שמתמקדים ברוחב פס.
  • ‫Hyperdisk Extreme: אופטימיזציה לביצועי IOPS. זוהי אפשרות טובה אם אתם פורסים עומסי עבודה עם ביצועים גבוהים, כמו מערכות לניהול מסדי נתונים.
  • ‫Hyperdisk ML: מותאם לעומסי עבודה של אימון AI/ML והסקת מסקנות שדורשים טעינה מהירה של משקלי המודל. בשונה מנפחי Hyperdisk אחרים, האפשרות הזו תומכת במצב גישה ReadOnlyMany, שמאפשר לכמה תרמילים לקרוא את אותם משקלי מודל בו-זמנית. האפשרות הזו מאפשרת לצמצם את מצב חוסר הפעילות של משאבי GPU/TPU בגלל צווארי בקבוק של זמן האחזור.

אפשרויות האחסון של Hyperdisk נתמכות ב-GKE Autopilot ובאשכולות רגילים.

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

אחסון בלוקים (Hyperdisk Storage Pool)

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

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

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

אחסון זמני ואחסון בלוקים גולמיים (כונן SSD מקומי)

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

אפשרות האחסון הזו נתמכת באשכולות GKE Standard. תמיכה ב-Autopilot ב-Local SSD זמינה בגרסת Preview במכונות A2 Ultra A100, באשכולות ובמאגרי צמתים שמופעלת בהם GKE מגרסה 1.27 ואילך.

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

למה כדאי להשתמש ב-SSD מקומי

השימוש באחסון SSD מקומי באשכולות GKE מתאים אם אתם צריכים שמירה במטמון פעיל למסדי נתונים ולניתוח בזמן אמת, או אחסון ארעי שעבר אופטימיזציה ל-flash ומציע את השהיות הנמוכות ביותר. אחסון מקומי ב-SSD יכול להיות יעיל במיוחד כשמשתמשים בו כשכבת מטמון לפני Cloud Storage לתרחישי שימוש ב-AI/ML, בעיבוד באצווה, בניתוח ובמסדי נתונים בזיכרון.

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

מערכת קבצים מקבילה (Google Cloud Managed Lustre)

‫Managed Lustre היא מערכת קבצים מקבילה מנוהלת עם רמת ביצועים גבוהה ב- Cloud de Confiance, שמשולבת עם GKE באמצעות מנהל התקן ה-CSI של Managed Lustre. הוא מיועד לעומסי עבודה תובעניים שדורשים אחסון מתמשך, ניתן להרחבה ובעל תפוקה גבוהה, במיוחד ב-AI/ML ובמחשוב עתיר ביצועים (HPC). אפשר גם להרחיב באופן דינמי את נפחי Lustre כדי לענות על דרישות אחסון גדלות בלי להפריע לאפליקציות. מנהל התקן ה-CSI של Managed Lustre מבצע אוטומציה של ניהול מחזור החיים של מופעי Managed Lustre, ומאפשר לכם להקצות להם משאבים ולגשת אליהם באמצעות אובייקטים סטנדרטיים של Kubernetes, כמו PersistentVolumes ו-PersistentVolumeClaims.

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

למה כדאי להשתמש באחסון Managed Lustre

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

  • ‫AI/ML: עומסי עבודה של אימון והסקת מסקנות שצריכים גישה למערכי נתונים גדולים.
  • HPC: סימולציות מדעיות והנדסיות בקנה מידה גדול.
  • דרישות אחסון דינמיות: עומסי עבודה שבהם דרישות האחסון גדלות עם הזמן, כי אפשר להגדיל את הקיבולת של נפחי Lustre בלי השבתה של האפליקציה.

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

מערכת קבצים ברשת (Filestore)

‫Filestore מספק מערכת קבצים משותפת מבוססת-ענן לנתונים לא מובנים, עם גישה למערכת קבצים ברשת (NFS). מופעי Filestore פועלים כשרתי קבצים ב- Cloud de Confiance ומספקים אחסון עמיד עם גישה של ReadWriteMany לאשכולות GKE. מופעי Filestore מופרדים מהמארח ולא דורשים פעולה ידנית רבה. מעבר לגיבוי בענן של עומסי עבודה מתבצע בצורה חלקה כי אין פעולות תשתית לצירוף או לניתוק של נפחים.

אפשרות האחסון הזו נתמכת באשכולות GKE Autopilot ו-Standard. אחסון ב-Filestore עם רמת השירות Enterprise מוגדר כברירת מחדל לזמינות אזורית, בעוד שרמות השירות האחרות מוגדרות לזמינות אזורית. האחסון ב-Filestore ב-GKE הוא קבוע, כלומר הנתונים שמאוחסנים במופעים יישארו גם אם ה-Pod שמשתמש בהם יסתיים.

למה כדאי להשתמש באחסון Filestore

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

כדי להשיג יעילות נוספת בעלויות, אפשר להשתמש בFilestore multishares for GKE כדי לשתף עד 80 PersistentVolumes במופע Filestore ברמת Enterprise בגודל 10 GiB ומעלה.

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

אחסון אובייקטים (Cloud Storage FUSE)

‫Cloud Storage הוא מאגר אובייקטים לנתונים בינאריים, לנתוני אובייקטים, ל-BLOB ולנתונים לא מובְנים. מנהל התקן ה-CSI של Cloud Storage FUSE מנהל את השילוב בין Cloud Storage FUSE לבין Kubernetes API כדי לצרוך נפחי אחסון באמצעות קטגוריות אחסון קיימות ב-Cloud Storage. אפשר להשתמש במנהל התקן ה-CSI של Cloud Storage FUSE כדי לטעון קטגוריות בתור מערכות קבצים בצמתים של GKE.

מנהל התקן ה-CSI של Cloud Storage FUSE תומך במצבי הגישה ReadWriteMany,‏ ReadOnlyMany ו-ReadWriteOnce באשכולות GKE Autopilot ו-Standard. הזמינות של אובייקטים ב-Cloud Storage תלויה באזור. הנתונים ב-Cloud Storage ב-GKE הם נתונים קבועים, כלומר הנתונים שמאוחסנים בדליים יישארו גם אם ה-Pod שמשתמש בהם יופסק.

למה כדאי להשתמש ב-Cloud Storage FUSE

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

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

גישה לאחסון אובייקטים של AI/ML באמצעות Run:ai Model Streamer

‫Run:ai Model Streamer הוא Python SDK שנועד להאיץ את הטעינה של מודלים גדולים של AI ליחידות GPU על ידי סטרימינג של משקלי המודל ישירות מאחסון אובייקטים, כמו Cloud Storage, לזיכרון ה-GPU. הפתרון הזה מבוסס על קוד פתוח ומשתמש בהטמעה של C++‎ עם ביצועים גבוהים כדי לקרוא טנסורים של מודלים במקביל. כך אפשר לקצר משמעותית את זמני ההפעלה הקרה של מנועי הסקה.

המודל streamer משתלב עם שרתי היקשים כמו vLLM ועובד עם מודלים שמאוחסנים ב-Cloud Storage. למרות שהסטרימר מאיץ את הגישה לנתונים, נתוני המודל הבסיסיים שמאוחסנים בקטגוריות של Cloud Storage נשארים קבועים, כלומר הנתונים יישארו גם אם ה-Pod שמשתמש בהם יופסק.

למה כדאי להשתמש ב-Run:ai Model Streamer

מומלץ להשתמש ב-Run:ai Model Streamer אם אתם צריכים להאיץ את זמני הטעינה של מודלים להסקת מסקנות, במיוחד כשניגשים לקובצי safetensors מ-Cloud Storage באמצעות מסגרות הגשה כמו vLLM או SGLang. הסטרימר נועד לטעון מודלים הרבה יותר מהר משיטות רגילות, וכך לשפר את השימוש הכולל במעבד הגרפי ואת היעילות של עומסי עבודה גדולים של AI.

כדי להתחיל להשתמש ב-GKE, אפשר לעיין במאמר האצת טעינת מודלים ב-GKE באמצעות Run:ai model streamer ו-vLLM.

מסדי נתונים מנוהלים

מסד נתונים מנוהל, כמו Cloud SQL או Spanner, מספק תקורה תפעולית מופחתת ומותאם לתשתית Cloud de Confiance. מסדי נתונים מנוהלים דורשים פחות מאמץ לתחזוקה ולתפעול מאשר מסד נתונים שפורס ישירות ב-Kubernetes.

למה כדאי להשתמש במסדי נתונים מנוהלים

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

‫GKE מספק תמיכה בחיבור לשירותי Cloud de Confiance מסדי נתונים מנוהלים, כולל:

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

פריטי מידע שנוצרו בתהליך פיתוח (Artifact) (Artifact Registry)

‫Artifact Registry הוא מנהל מאגרים לקובצי אימג' של קונטיינרים, לחבילות של מערכות הפעלה ולחבילות שפה שאתם יוצרים ומפרסים.

למה כדאי להשתמש ב-Artifact Registry

‫Artifact Registry היא אפשרות מתאימה לאחסון תמונות פרטיות של קונטיינרים, תרשימי Helm ופריטי מידע אחרים שנוצרים בתהליך בנייה.

כדי לשלוף תמונות ממאגרי Docker ב-Artifact Registry אל GKE, אפשר לעיין במאמר פריסה ב-Google Kubernetes Engine במסמכי התיעוד של Artifact Registry.

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