כונני SSD מקומיים הם כונני SSD בגודל קבוע, שאפשר לטעון למכונה וירטואלית אחת ב-Compute Engine. אתם יכולים להשתמש ב-Local SSD ב-GKE כדי לקבל אחסון בעל ביצועים גבוהים שאינו מתמיד (זמני) ומחובר לכל צומת באשכול. בנוסף, התפוקה של אחסוני SSD מקומיים גבוהה יותר וזמן האחזור שלהם קצר יותר מדיסקים סטנדרטיים.
בגרסה 1.25.3-gke.1800 ואילך, אתם יכולים להגדיר מאגר צמתים של GKE לשימוש ב-SSD מקומי עם ממשק NVMe לאחסון זמני מקומי או לאחסון בלוקים גולמיים.
אם אתם משתמשים ב-GKE עם אשכולות Standard, אתם יכולים לצרף נפחי Local SSD לצמתים כשאתם יוצרים מאגרי צמתים. כך משפרים את הביצועים של האחסון הארעי לעומסי העבודה שמשתמשים ב-emptyDir Volumes או ב-local PersistentVolumes. אתם יכולים ליצור מאגרי צמתים עם כונני SSD מקומיים במסגרת מגבלות סוג המכונה של האשכול והמכסות של הפרויקט.
דיסק SSD מקומי מחובר רק לצומת אחד. הצמתים עצמם הם זמניים, כלומר אפשר לתזמן עומס עבודה לצומת אחר. כדי לוודא שעומסי עבודה שדורשים כונני SSD מקומיים מתוזמנים לצמתים המתאימים, משתמשים בהעדפת צומת.
לדוגמה, משתמשים בתווית הצומת cloud.google.com/gke-ephemeral-storage-local-ssd: "true".
כשמגדירים כונני SSD מקומיים, GKE טוען באופן אוטומטי את הספריות הבאות לנפח של ה-SSD המקומי כדי לשפר את הביצועים: /var/lib/kubelet, /var/log/pods ו-/var/lib/containerd. כך אפשר לגשת מהר יותר לנתוני kubelet קריטיים, ליומני Pod ולקובצי זמן ריצה של קונטיינרים.
למידע נוסף על היתרונות והמגבלות של כונני SSD מקומיים, כמו ביצועים ומספר כונני ה-SSD המותרים לכל סוג מכונה, קראו את המאמר כונני SSD מקומיים במסמכי התיעוד של Compute Engine.
למה כדאי לבחור ב-SSD מקומי ל-GKE
כדאי להשתמש ב-SSD מקומי אם עומסי העבודה שלכם עומדים בדרישות הבאות:
- אתם רוצים להריץ אפליקציות שמורידות ומעבדות נתונים, כמו AI או למידת מכונה, ניתוח נתונים, עיבוד באצווה, שמירה במטמון מקומי ומסדי נתונים בזיכרון.
- לאפליקציות שלכם יש צורכי אחסון מיוחדים ואתם רוצים גישה לבלוקים גולמיים באחסון זמני עם ביצועים גבוהים.
- אתם רוצים להריץ אפליקציות נתונים מיוחדות ולהפעיל נפחי SSD מקומיים כמו מטמון ברמת הצומת בשביל ה-Pods. אתם יכולים להשתמש בגישה הזו כדי לשפר את הביצועים של אפליקציות של מסדי נתונים בזיכרון, כמו Aerospike או Redis.
אחסון זמני
מומלץ להשתמש באפשרות --ephemeral-storage-local-ssd כדי להקצות כונן SSD מקומי לאחסון זמני של צומת (זוהי ברירת המחדל אם משתמשים בסדרת מכונות מהדור השלישי).
בגישה הזו, נפחי emptyDir, שכבות שניתנות לכתיבה בקונטיינר וקובצי אימג' שביחד מרכיבים את האחסון הזמני של הצומת, נמצאים ב-SSD מקומי. היתרונות כוללים רוחב פס משופר של קלט/פלט בהשוואה ל-Persistent Disk שמוגדר כברירת מחדל, וזמני הפעלה משופרים של Pod.
כשמשתמשים ב-SSD מקומי לאחסון זמני של צומת, אמצעי האחסון של ה-SSD המקומי של דיסק האתחול לא זמינים לשימושים אחרים. אל תשנו את התקני ה-SSD המקומיים, כמו /dev/nvme*, ישירות באמצעות Daemonset, HostPath או מנגנון אחר עם הרשאות, אחרת הצומת עלול להיכשל.
אם אתם צריכים שליטה מדויקת על נפחי ה-SSD המקומיים, השתמשו בגישה של בלוק גולמי.
אחסון בהתקן בלוקים
אחסון בהתקן בלוקים מאפשר גישה אקראית לנתונים בבלוקים בגודל קבוע. יש אפליקציות מיוחדות שדורשות גישה ישירה לאחסון של התקן בלוקים, כי למשל שכבת מערכת הקבצים מוסיפה תקורה מיותרת.
תרחישים נפוצים לשימוש באחסון של התקני בלוקים כוללים:
- מסדי נתונים שבהם הנתונים מאורגנים ישירות באחסון הבסיסי.
- תוכנה שמטמיעה בעצמה סוג כלשהו של שירות אחסון (מערכות אחסון מוגדרות תוכנה).
בגרסה v1.25.3-gke.1800 של GKE ואילך, אפשר ליצור אשכולות ומאגרי צמתים עם כונני NVMe SSD מקומיים של בלוקים גולמיים, באמצעות האפשרות --local-nvme-ssd-block. לאחר מכן תוכלו להתאים אישית את אחסון הבלוקים על ידי עיצוב מערכת קבצים לבחירתכם (כמו ZFS או HDFS) והגדרת RAID. האפשרות הזו מתאימה אם אתם צריכים אמצעי בקרה נוספים כדי להריץ עומסי עבודה שדורשים גישה לאחסון בלוקים שמגובה ב-SSD מקומי.
אתם יכולים גם להשתמש בגישת הגישה לבלוקים עם Local SSD אם אתם רוצים מטמון נתונים מאוחד לשיתוף נתונים בין Pods, והנתונים קשורים למחזור החיים של הצומת. כדי לעשות את זה, מתקינים DaemonSet עם הגדרת RAID, מעצבים מערכת קבצים ומשתמשים ב-PersistentVolume מקומי כדי לשתף נתונים בין Pods.
דרישות המחשב
הדרך שבה מקצים כונני SSD מקומיים לאשכולות GKE ולמאגרי הצמתים תלויה בסוג המכונה הבסיסית. GKE תומך בנפחי SSD מקומיים בסדרות המכונות מהדור הראשון, השני והשלישי של Compute Engine. כדי להשתמש בנפחי SSD מקומיים נדרש סוג מכונה n1-standard-1 או גדול יותר.
אין תמיכה בסוג המכונה שמוגדר כברירת מחדל, e2-medium.
כדי לזהות את סדרת המכונות, משתמשים במספר שבשם של סוג המכונה. לדוגמה, מכונות N1 הן מהדור הראשון ומכונות N2 הן מהדור השני.
רשימה של סדרות וסוגים זמינים של מכונות מופיעה במאמר השוואה בין משפחות של מכונות ומשאבים במסמכי התיעוד של Compute Engine.
ב-GKE אי אפשר להשתמש בסדרת המכונות C4N עם כונני SSD מקומיים. בסדרת המכונות הזו יש תמיכה ב-SSD מקומי בגרסת טרום-השקה (Preview) ב-Compute Engine.
הדרישות לגבי סדרות מכונות מהדור הראשון והשני
כדי להשתמש בסדרת מכונות מהדור הראשון או השני עם Local SSD, באשכול או במאגר הצמתים צריכה לפעול גרסת GKE 1.25.3-gke.1800 ואילך.
כדי להקצות כונני SSD מקומיים בסדרת מכונות מהדור הראשון או השני, צריך לציין את מספר הכוננים שרוצים להשתמש בהם עם ה-VM. במאמר בחירת מספר תקין של כונני SSD מקומיים שבמסמכי התיעוד של Compute Engine, תוכלו למצוא רשימה של סדרות מכונות ומספר כונני ה-SSD המקומיים שאפשר להוסיף לכל אחת מהן.
דרישות לסדרות מכונות מהדור השלישי והרביעי
כדי להשתמש בסדרת מכונות מהדור השלישי עם Local SSD, באשכול או במאגר הצמתים צריכה לפעול אחת מגרסאות GKE הבאות או גרסה חדשה יותר:
- 1.25.13-gke.200 עד 1.26
- 1.26.8-gke.200 עד 1.27
- 1.27.5-gke.200 עד 1.28
- 1.28.1-gke.200 עד 1.29
אם אתם רוצים להשתמש בסדרת מכונות מהדור הרביעי עם Local SSD, באשכול או במאגר הצמתים צריכה לפעול אחת מהגרסאות הבאות של GKE או גרסה עדכנית יותר:
- 1.32.1-gke.1357000
בסדרות מכונות מהדור השלישי והרביעי, כל סוג מכונה מוגדר מראש בלי כונני SSD מקומיים או עם כמות קבועה של נפחי SSD מקומיים. לא מציינים את מספר כונני ה-SSD המקומיים שרוצים לכלול. במקום זאת, הקיבולת של כונן ה-SSD המקומי שזמינה לאשכולות מוגדרת באופן משתמע כחלק מצורת ה-VM.
במאמר בחירת מספר תקין של כונני SSD מקומיים שבמסמכי התיעוד של Compute Engine, תוכלו למצוא רשימה של סדרות המכונות ומספר כונני ה-SSD המקומיים שאפשר להוסיף לכל אחת מהן.
דפוס השימוש בנפחי SSD מקומיים
כדי להשתמש בנפחי Local SSD באשכולות, פועלים לפי השלבים הכלליים הבאים:
- הקצאת מאגר צמתים עם כונני SSD מקומיים מצורפים: כדי ליצור מאגר צמתים ב-GKE עם כונני SSD מקומיים מצורפים, צריך להעביר את הפרמטר של האחסון הזמני או של אחסון הבלוקים הגולמי כשמפעילים את הפקודה
create cluster. הגדרת הפרמטרים של Local SSD יוצרת מאגר צמתים של GKE עם Local SSD מצורף, שמוגדר כנפח אחסון מקומי זמני או כנפח אחסון גולמי של בלוקים, בהתאם לפרמטרים שבחרתם. למידע נוסף על האפשרויות להקצאת כונני SSD מקומיים, ראו פרמטרים של כונני SSD מקומיים. - גישה לנתונים מנפחי SSD מקומיים: כדי להשתמש בנתונים מנפחי SSD מקומיים, אתם יכולים להשתמש במבנה של Kubernetes כמו emptyDir או נפח מקומי קבוע. מידע נוסף על האפשרויות האלה זמין במאמר גישה ל-SSD מקומי.
פרמטרים של SSD מקומי ב-GKE
בטבלה הבאה מופיע סיכום של הפרמטרים המומלצים ש-GKE מספק להקצאת אחסון ב-SSD מקומי באשכולות. אפשר להשתמש ב-CLI של gcloud כדי להעביר את הפרמטרים האלה.
| סוג ה-SSD המקומי | פקודת ה-CLI של gcloud | זמינות GKE | פרופיל SSD מקומי |
|---|---|---|---|
| אחסון זמני ב-SSD מקומי | gcloud container clusters create |
v1.25.3-gke.1800 ואילך |
טכנולוגיית אחסון: NVMe הנתונים משותפים בין פודים: לא מחזור החיים של הנתונים: Pod גודל והצורך במערך RAID: עד 9TiB. GKE מגדיר את RAID באופן אוטומטי מאחורי הקלעים. פורמט: מערכת קבצים (Kubernetes emptyDir) שילוב עם מתזמן Kubernetes: משולב באופן מלא כברירת מחדל. מתזמן Kubernetes עוזר לוודא שיש מקום פנוי בצומת לפני המיקום, ומשנה את קנה המידה של הצמתים לפי הצורך. במאמר הקצאה ושימוש באחסון זמני שמגובה ב-SSD מקומי מוסבר איך משתמשים בפרמטר הזה של ה-API. |
| בלוק SSD מקומי ב-NVMe | gcloud container clusters create |
v1.25.3-gke.1800 ואילך |
טכנולוגיית אחסון: NVMe הנתונים משותפים בין Pods: כן, באמצעות אמצעי אחסון מקומיים. מחזור החיים של הנתונים: צומת גודל והצורך במערך RAID: עד 9TiB. כדי להגדיר מערך RAID בגודל גדול יותר, צריך להגדיר אותו ידנית. פורמט: בלוק גולמי שילוב עם מתזמן Kubernetes: לא, כברירת מחדל. אתם צריכים לוודא שיש מספיק קיבולת בצמתים ולטפל ב"שכנים רועשים". אם תבחרו להשתמש ב-PV מקומי, התזמון יהיה משולב. במאמר הקצאה ושימוש באחסון בלוקים גולמיים שמגובה ב-SSD מקומי מוסבר איך משתמשים בפרמטר הזה של ה-API. |
תמיכה בפרמטרים קיימים של Local SSD
בטבלה הבאה מפורטים הפרמטרים הקיימים של Local SSD והתחליפים המומלצים שלהם:
| פרמטרים קיימים של SSD מקומי | פקודת ה-CLI של gcloud | פרופיל SSD מקומי | גרסת GA מומלצת של הפרמטרים של Local SSD |
|---|---|---|---|
| הפרמטר Local SSD Count | gcloud container clusters create |
טכנולוגיית אחסון: SCSI שיתוף נתונים בין Pods: כן, באמצעות אמצעי אחסון מקומיים (PV) מחזור החיים של הנתונים: צומת גודל והצורך בהגדרת RAID: 375GiB. כדי להגדיר RAID בגדלים גדולים יותר, צריך לעשות את זה באופן ידני. פורמט: מערכת קבצים (ext-4) שילוב עם מתזמן Kubernetes: לא כברירת מחדל. אתם צריכים לוודא שיש מספיק קיבולת בצמתים ולטפל בבעיות של "שכנים רועשים". אם אתם מצטרפים ל-PV מקומי, התזמון משולב. |
gcloud container clusters create |
| פרמטר של אחסון זמני (בטא) | gcloud beta container clusters create |
טכנולוגיית אחסון: NVMe שיתוף נתונים בין פודים: לא מחזור החיים של הנתונים: Pod גודל והצורך בהגדרת RAID: עד 9TiB. GKE מגדיר את RAID באופן אוטומטי מאחורי הקלעים. פורמט: מערכת קבצים (Kubernetes emptyDir) שילוב עם מתזמן Kubernetes: משולב באופן מלא כברירת מחדל. מתזמן Kubernetes עוזר לוודא שיש מקום בצמתים לפני ההצבה, ומשנה את קנה המידה של הצמתים לפי הצורך. |
gcloud container clusters create |
| פרמטר של נפחי SSD מקומיים (אלפא) | gcloud alpha container clusters create |
טכנולוגיית אחסון: NVMe או SCSI שיתוף נתונים בין פודים: לא מחזור החיים של הנתונים: צומת גודל והצורך בהגדרת RAID: 375GiB. כדי להגדיר RAID בגדלים גדולים יותר, צריך לעשות את זה ידנית. פורמט: מערכת קבצים (ext-4) או בלוק גולמי שילוב עם מתזמן Kubernetes: לא כברירת מחדל. צריך לוודא שיש קיבולת בצמתים ולטפל בבעיות של שכנים רועשים. |
gcloud container clusters create |
גישה ל-SSD מקומי
אפשר לגשת לנפחי SSD מקומיים באחת מהשיטות הבאות.
אמצעי אחסון emptyDir
בגרסה v1.25.3-gke.1800 של GKE ואילך, אתם יכולים להשתמש באחסון זמני כנפח emptyDir שמגובה ב-SSD מקומי, באמצעות האפשרות --ephemeral-storage-local-ssd. אנחנו ממליצים על הגישה הזו ברוב המקרים, כולל אפליקציות שצריכות שטח זמני לנתונים זמניים בביצועים גבוהים.
ב-GKE אפשר להגדיר מאגר צמתים כדי לטעון אחסון זמני של צמתים ב-SSD מקומי עם ממשק NVMe.
מידע נוסף זמין בדוגמה הזו.
נפח אחסון מקומי קבוע
אמצעי אחסון מתמיד מקומי מייצג דיסק מקומי שמחובר לצומת יחיד. אמצעי אחסון מקומיים קבועים מאפשרים לשתף משאבי SSD מקומיים בין Pods. מכיוון שהדיסק המקומי הוא דיסק SSD מקומי, הנתונים עדיין זמניים.
אנחנו ממליצים על הגישה הזו אם אחד מהדברים הבאים פועל באשכול:
- עומסי עבודה שמשתמשים ב-StatefulSets וב-volumeClaimTemplates.
- עומסי עבודה שמשתפים מאגרי צמתים. אפשר להזמין כל נפח של Local SSD באמצעות PersistentVolumeClaim, ו-HostPaths ספציפיים לא מקודדים ישירות במפרט של ה-Pod.
- פודים שדורשים כוח משיכה של נתונים לאותו Local SSD. Pod תמיד מתוזמן לאותו צומת כמו ה-PersistentVolume המקומי שלו.
למידע נוסף, אפשר לעיין בדוגמה הזו ובמסמכי התיעוד של Kubernetes בקוד פתוח בנושא אמצעי אחסון.
טיפול בתחזוקת המארח
חלק מהצמתים ב-GKE שמשתמשים בכונני SSD מקומיים, כמו מכונות מסוג Z3 עם יותר מ-18TiB של Titanium SSD מחובר, לא תומכים במיגרציה פעילה במהלך תחזוקת המארח. במקום זאת, המכונה הווירטואלית נעצרת ומופעלת מחדש במקום. לרשימה של משפחות מכונות עם התנהגויות ספציפיות במהלך אירועי תחזוקה, ראו מידע על אירועים במארח במסמכי התיעוד של Compute Engine.
בגלל האפשרות לזמן השבתה ממושך של צמתים בסוגי מכונות שמופעלות מחדש, כדאי לתכנן את האפליקציות כך שיהיו עמידות, ולקחת בחשבון ש-Pods יופסקו ויתוזמנו מחדש בצמתים אחרים.
בדומה לצמתים עם יחידות GPU ו-TPU מצורפות, אתם יכולים להגדיר את האשכול כך שינהל את אירועי התחזוקה האלה בצורה חלקה. הרכיב GKE maintenance-handler מזהה באופן אוטומטי פעולות תחזוקה קרובות בצמתים עם כונני SSD מקומיים. לפני שמתחילה פעולת התחזוקה, ה-handler מסמן את הצומת כדי למנוע תזמון של Pods חדשים, ואז מפנה בצורה בטוחה את ה-Pods הקיימים. כך אפשר לתזמן מחדש את ה-Pods בצמתים זמינים אחרים באשכול, בהתאם ל-PodDisruptionBudgets שהגדרתם.
הוראות מפורטות להגדרת עומסי העבודה לניהול האירועים האלה מופיעות במאמר ניהול השיבושים בצומתי GKE שלא עוברים מיגרציה פעילה.
הגבלות
האפליקציה צריכה לטפל בצורה חלקה באובדן הגישה לנתונים בנפחי SSD מקומיים. נתונים שנכתבים בדיסק SSD מקומי לא נשמרים כשמוחקים, מתקנים או משדרגים את ה-Pod או הצומת, או כשיש שגיאה שבעקבותיה אי אפשר לשחזר.
הפרמטר של אחסון זמני ב-SSD מקומי מגדיר את נפחי ה-SSD המקומיים כך שיהיה להם מחזור חיים של נתונים שמבוסס על Pod, והפרמטר של בלוק NVMe ב-SSD מקומי מגדיר את נפחי ה-SSD המקומיים כך שיהיה להם מחזור חיים של נתונים שמבוסס על צומת.
אם אתם צריכים אחסון מתמיד, מומלץ להשתמש באפשרות של אחסון עמיד (כמו Persistent Disk, Filestore או Cloud Storage). אתם יכולים גם להשתמש ברפליקות אזוריות כדי לצמצם את הסיכון לאובדן נתונים במהלך פעולות במחזור החיים של האשכול או של האפליקציה.
אי אפשר לשנות את הגדרות התצורה של Local SSD אחרי שיוצרים את מאגר הצמתים. אי אפשר להפעיל, להשבית או לעדכן את ההגדרה של Local SSD במאגר צמתים קיים. כדי לבצע שינויים, צריך למחוק את מאגר הצמתים וליצור מאגר חדש.
פודים שמשתמשים ב-emptyDir משתמשים ב-SSD מקומי באופן שקוף, אבל זה נכון לכל הפודים בכל הצמתים במאגר הצמתים הזה. ב-GKE אי אפשר להשתמש באותו מאגר צמתים גם ב-Pods שמשתמשים בנפחי emptyDir של Local SSD שמגובים ב-Local SSD, וגם ב-Pods שמשתמשים בנפחי emptyDir שמגובים בדיסק אתחול של צומת. אם יש לכם עומסי עבודה שמשתמשים בנפחי emptyDir שמגובים בדיסק אתחול של צומת, תזמנו את עומסי העבודה במאגר צמתים אחר.
אשכולות Autopilot והקצאת צמתים אוטומטית תומכים בכונני SSD מקומיים רק באמצעות ComputeClasses בהתאמה אישית
משתמשים בכונן SSD מקומי כאחסון זמני לעומסי עבודה שפועלים במכונות וירטואליות מסוג Z3, במכונות וירטואליות מסוג Z4D או במכונות וירטואליות מסוג Z4M שמותאמות לאחסון. אפשר לבצע מיגרציה פעילה במכונות האלה בתנאים הבאים:
מכונות וירטואליות מסוג Z3 עם Titanium SSD בנפח של 18TiB או פחות, אבל מכונות וירטואליות מסוג Z3 עם Titanium SSD בנפח של יותר מ-18TiB מסתיימות במהלך אירועי תחזוקה. מידע נוסף זמין במאמר חוויית התחזוקה של מכונות Z3. מכונות וירטואליות מסוג Z3 עם יותר מ-18TiB של Titanium SSD מסתיימות, ולכן יכול להיות שהנתונים ב-Local SSD של הצמתים לא יהיו זמינים במהלך אירועי תחזוקה, ואין הבטחה לשחזור הנתונים אחרי התחזוקה. מידע נוסף זמין במאמר שמירת הדיסק לאחר סיום המכונה.
מכונות וירטואליות מסוג Z4D עם Titanium SSD מחובר בנפח של 42 TiB או פחות, אבל מכונות וירטואליות מסוג Z4D עם Titanium SSD מחובר בנפח של יותר מ-42 TiB מסתיימות במהלך אירועי תחזוקה.
במכונות וירטואליות מסוג Z4M עם Titanium SSD בנפח של עד 48 TiB, אפשר לבצע מיגרציה פעילה אם לא משתמשים ב-Cloud RDMA. מכונות וירטואליות מסוג Z4M עם יותר מ-48TiB של Titanium SSD מחובר, וגם כל מכונה וירטואלית מסוג Z4M שמוגדרת לשימוש ב-Cloud RDMA, מסתיימות במהלך אירועי תחזוקה.
המאמרים הבאים
- איך מקצים אחסון זמני שמגובה ב-SSD מקומי ומשתמשים בו
- איך מקצים ומשתמשים באחסון בלוקים גולמיים שמגובה ב-SSD מקומי
- איך משתמשים בדיסקים ייעודיים לאחסון מתמיד כנפחים זמניים
- איך יוצרים אמצעי אחסון
- איך משתמשים במנהל ההתקן של CSI לדיסק Persistent Disk ב-Compute Engine