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

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

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

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

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

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

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

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

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

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

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

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

  • במאמר אפשרויות אחסון במשאבי העזרה של Compute Engine אפשר לקרוא על סוגי הדיסקים שזמינים.
  • מנהל התקן ה-CSI של דיסק אחסון מתמיד (persistent disk) ב-Compute Engine הוא הדרך העיקרית שבה משתמשים באחסון של דיסק אחסון מתמיד עם GKE. הוראות מפורטות זמינות במאמר בנושא שימוש ב-Compute Engine Persistent Disk CSI Driver.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

‫Filestore מספק מערכת קבצים שיתופית מבוססת-ענן לנתונים לא מובנים, עם גישה למערכת קבצים ברשת (NFS). מופעי Filestore פועלים כשרתי קבצים ב- Google Cloud ומספקים אחסון עמיד עם גישה של 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, מספק תקורה תפעולית מופחתת ומותאם לתשתית Google Cloud. מסדי נתונים מנוהלים דורשים פחות מאמץ לתחזוקה ולהפעלה מאשר מסד נתונים שפורס ישירות ב-Kubernetes.

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

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

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

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

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

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

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

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

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

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