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

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

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

אחסון בלוקים (Persistent Disk)

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

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

כברירת מחדל, אמצעי אחסון של דיסקים לאחסון מתמיד הם משאבים של תחום מוגדר (נשמרים בתחום אחד באזור). אתם יכולים ליצור נפחי אחסון של דיסקים לאחסון מתמיד (persistent disks) אזוריים (שנשמרים בשני אזורים באותו אזור). אפשר גם לצרף נפח של דיסק אחסון מתמיד (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 ואילך.
  • Persistent Disk לביצועים: מתאים לניתוח נתונים בהרחבה, למסדי נתונים ולשמירת נתונים במטמון באופן קבוע. האפשרות הזו מתאימה לעומסי עבודה שבהם הביצועים חשובים במיוחד. מגובה בכונני SSD.
  • ‫דיסק מתמיד סטנדרטי: מתאים לעומסי עבודה של נתונים גדולים וחישובים גדולים. האפשרות הזו היא סוג הדיסק הכי חסכוני. מגובה על ידי כוננים קשיחים (HDD) רגילים.
  • ‫Extreme Persistent Disk: מתאים לאפליקציות ארגוניות כמו SAP HANA ו-Oracle. האפשרות הזו מציעה את הביצועים הכי טובים כדי לענות על הצרכים של מסדי הנתונים הכי גדולים בזיכרון. מגובה בכונני SSD. לאפליקציות שבהן הביצועים הם קריטיים, ושבהן Persistent Disk לא מספק ביצועים מספיקים, כדאי להשתמש בדיסקים של Hyperdisk Extreme.

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

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

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

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

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

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

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

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

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

אחסון בלוקים (מאגר אחסון Hyperdisk)

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

באשכולות רגילים אפשר להשתמש גם בדיסקים לאתחול Hyperdisk (למערכות הפעלה) וגם ב-Hyperdisks מצורפים (לאחסון נתונים) כחלק ממאגר אחסון. אשכולות 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, בעיבוד ברצף (batch processing), בניתוח ובמסדי נתונים בזיכרון.

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

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

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

אפשרות האחסון הזו נתמכת באשכולות GKE Autopilot ובאשכולות רגילים שמריצים צמתים של מערכת הפעלה שמותאמת לקונטיינרים. אחסון 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 הוא מאגר אובייקטים לנתונים בינאריים, נתוני אובייקטים, בלובים ונתונים לא מובְנים. מנהל התקן ה-CSI של Cloud Storage FUSE מנהל את השילוב בין Cloud Storage FUSE לבין Kubernetes APIs כדי לצרוך נפחי אחסון באמצעות קטגוריות אחסון קיימות ב-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 הוא ערכת SDK של Python שנועדה להאיץ את הטעינה של מודלים גדולים של AI אל מעבדי GPU על ידי סטרימינג של משקלי המודל ישירות מאחסון אובייקטים, כמו Cloud Storage, לזיכרון ה-GPU. הפתרון הזה מבוסס על קוד פתוח ומשתמש בהטמעה של C++‎ עם ביצועים גבוהים כדי לקרוא טנסורים של מודלים במקביל. כך אפשר לקצר באופן משמעותי את הזמן שנדרש למנועי היקש להתחיל לפעול.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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