כונני SSD מקומיים הם כונני SSD בגודל קבוע, שאפשר לטעון אותם במכונה וירטואלית אחת ב-Compute Engine. אפשר להשתמש ב-SSD מקומי ב-GKE כדי לקבל אחסון עם ביצועים גבוהים שלא נשמר (זמני) שמצורף לכל צומת באשכול. בנוסף, התפוקה של אחסוני SSD מקומיים גבוהה יותר וזמן האחזור שלהם קצר יותר מדיסקים רגילים.
בגרסה 1.25.3-gke.1800 ואילך, אפשר להגדיר מאגר צמתים של GKE לשימוש ב-SSD מקומי עם ממשק NVMe לאחסון מקומי זמני או לאחסון בלוקים גולמיים.
אם אתם משתמשים ב-GKE עם אשכולות רגילים, אתם יכולים לצרף נפחי 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 המותרים לכל סוג מכונה, זמין במאמר Local SSDs (כונני SSD מקומיים) במסמכי התיעוד של Compute Engine.
למה כדאי לבחור ב-SSD מקומי ל-GKE
SSD מקומי הוא בחירה טובה אם לעומסי העבודה שלכם יש אחת מהדרישות הבאות:
- אתם רוצים להריץ אפליקציות שמורידות ומעבדות נתונים, כמו AI או למידת מכונה, ניתוח נתונים, עיבוד באצווה, שמירה במטמון מקומי ומסדי נתונים בזיכרון.
- לאפליקציות שלכם יש צרכים מיוחדים באחסון ואתם רוצים גישה לבלוקים גולמיים באחסון זמני עם ביצועים גבוהים.
- אתם רוצים להפעיל אפליקציות נתונים ייעודיות, ורוצים להפעיל נפחי SSD מקומיים כמו מטמון ברמת הצומת עבור ה-Pods שלכם. אתם יכולים להשתמש בגישה הזו כדי לשפר את הביצועים של אפליקציות של מסדי נתונים בזיכרון כמו Aerospike או Redis.
שטח אחסון זמני
מומלץ להשתמש באפשרות --ephemeral-storage-local-ssd כדי להקצות SSD מקומי לאחסון זמני של צמתים (זו ברירת המחדל אם משתמשים בסדרת מכונות מהדור השלישי).
בגישה הזו, נפחי ה-emptyDir, השכבות שניתנות לכתיבה בקונטיינר והתמונות שמרכיבות יחד את האחסון הזמני של הצומת ממוקמים ב-SSD מקומי. היתרונות כוללים רוחב פס משופר של קלט/פלט בהשוואה לדיסק מתמשך שמוגדר כברירת מחדל, וזמני הפעלה משופרים של Pod.
השימוש ב-Local SSD לאחסון זמני של צמתים אומר שנפחי ה-Local SSD של דיסק האתחול לא זמינים לשימושים אחרים. אל תשנו את מכשירי ה-SSD המקומיים, כמו /dev/nvme*, ישירות באמצעות Daemonset עם הרשאות, HostPath או מנגנון אחר. אחרת, יכול להיות שהצומת ייכשל.
אם אתם צריכים שליטה מדויקת בנפחי ה-SSD המקומיים, עדיף להשתמש בגישה של בלוק גולמי.
חסימת נפח האחסון במכשיר
חסימת אחסון במכשיר מאפשרת גישה אקראית לנתונים בבלוקים בגודל קבוע. אפליקציות מיוחדות מסוימות דורשות גישה ישירה לאחסון של מכשיר בלוק, כי למשל, שכבת מערכת הקבצים מוסיפה תקורה מיותרת.
דוגמאות לתרחישים נפוצים שבהם משתמשים באחסון של מכשיר חסימה:
- מסדי נתונים שבהם הנתונים מאורגנים ישירות באחסון הבסיסי.
- תוכנה שמטמיעה בעצמה סוג מסוים של שירות אחסון (מערכות אחסון מוגדרות בתוכנה).
ב-GKE מגרסה v1.25.3-gke.1800 ואילך, אפשר ליצור אשכולות ומאגרי צמתים עם כונני 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 מקומי זמינה בסדרת המכונות הזו בתצוגה מקדימה ב-Compute Engine.
הדרישות לגבי סדרת מכונות מהדור הראשון והשני
כדי להשתמש בסדרת מכונות מהדור הראשון או השני עם SSD מקומי, האשכול או מאגר הצמתים צריכים להריץ את GKE מגרסה 1.25.3-gke.1800 ואילך.
כדי להקצות Local SSD בסדרת מכונות מהדור הראשון או השני, מציינים את מספר נפחי ה-Local SSD שבהם רוצים להשתמש במכונה הווירטואלית. רשימה של סדרות מכונות ומספרים מקסימליים של SSD מקומיים שאפשר להשתמש בהם זמינה במאמר בחירת מספר תקין של SSD מקומיים במסמכי התיעוד של Compute Engine.
דרישות של סדרות מכונות מהדור השלישי והרביעי
אם רוצים להשתמש בסדרת מכונות מהדור השלישי עם 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
אם רוצים להשתמש בסדרת מכונות מהדור הרביעי עם SSD מקומי, האשכול או מאגר הצמתים צריכים להריץ אחת מהגרסאות הבאות של GKE או גרסה מאוחרת יותר:
- 1.32.1-gke.1357000
בסדרות מכונות מהדור השלישי והרביעי, כל סוג מכונה מוגדר מראש בלי כונן SSD מקומי או עם כמות קבועה של נפחי אחסון של כונני SSD מקומיים. לא מציינים את מספר נפחי ה-Local SSD שרוצים לכלול. במקום זאת, קיבולת ה-SSD המקומי שזמינה לאשכולות מוגדרת באופן מרומז כחלק מהצורה של מכונת ה-VM.
רשימה של סדרות מכונות ומספרים מקסימליים של SSD מקומיים שאפשר להשתמש בהם מופיעה במאמר בחירת מספר תקין של SSD מקומיים במסמכי התיעוד של Compute Engine.
דפוס השימוש בנפחי אחסון של SSD מקומי
כדי להשתמש בכרכים של 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 עוזר לוודא שיש מקום בצומת לפני ההצבה, ומשנה את גודל הצמתים אם צריך. מידע נוסף על השימוש בפרמטר הזה של ה-API מופיע במאמר בנושא הקצאה ושימוש באחסון זמני שמגובה על ידי SSD מקומי. |
| בלוק NVMe SSD מקומי | gcloud container clusters create |
v1.25.3-gke.1800 ואילך |
טכנולוגיית אחסון: NVMe האם הנתונים משותפים בין תאים: כן, באמצעות PV מקומיים. מחזור חיים של נתונים: צומת גודל וצורך בהגדרת RAID: עד 9TiB. צריך להגדיר RAID ידנית לגדלים גדולים יותר. פורמט: בלוק גולמי שילוב של מתזמן Kubernetes: לא, כברירת מחדל. צריך לוודא שיש קיבולת בצמתים ולטפל בבעיות שנובעות משכנים רועשים. אם תפעילו את התכונה 'ערך המרה מקומי', התזמון ישולב. מידע נוסף על השימוש בפרמטר הזה של ה-API מופיע במאמר הקצאה ושימוש באחסון בלוקים גולמיים שמגובה על ידי SSD מקומי. |
תמיכה בפרמטרים קיימים של SSD מקומי
בטבלה הבאה מפורטים הפרמטרים הקיימים של Local SSD והחלופות המומלצות שלהם:
| פרמטרים קיימים של אחסון SSD מקומי | פקודה ב-CLI של gcloud | פרופיל SSD מקומי | גרסת GA מומלצת של הפרמטרים של כונן SSD מקומי |
|---|---|---|---|
| פרמטר Local SSD Count | gcloud container clusters create |
טכנולוגיית אחסון: SCSI נתונים שמשותפים בין פודים: כן, באמצעות PV מקומיים מחזור חיים של נתונים: צומת גודל והצורך בהגדרת RAID: 375 GiB. צריך להגדיר RAID באופן ידני לגדלים גדולים יותר. פורמט: מערכת קבצים (ext-4) שילוב של מתזמן Kubernetes: לא כברירת מחדל. צריך לוודא שיש קיבולת בצמתים ולטפל בבעיות שנובעות משימוש יתר במשאבים. אם תפעילו את האפשרות 'הצגת נתוני המרות מקומיות', התזמון ישולב. |
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: 375 GiB. צריך להגדיר RAID באופן ידני לגדלים גדולים יותר. פורמט: מערכת קבצים (ext-4) או בלוק גולמי שילוב של מתזמן Kubernetes: לא כברירת מחדל. צריך לוודא שיש קיבולת בצמתים ולטפל בבעיית השכנים הרועשים. |
gcloud container clusters create |
גישה ל-SSD מקומי
אפשר לגשת לנפחי Local SSD באחת מהשיטות הבאות.
נפח emptyDir
ב-GKE מגרסה v1.25.3-gke.1800 ואילך, אפשר להשתמש באחסון זמני כנפח emptyDir שמגובה על ידי Local SSD, באמצעות האפשרות --ephemeral-storage-local-ssd. מומלץ להשתמש בגישה הזו ברוב המקרים, כולל באפליקציות שזקוקות לשטח אחסון זמני ומהיר.
ב-GKE אפשר להגדיר מאגר צמתים להטמעה של אחסון זמני בצומת ב-SSD מקומי עם ממשק NVMe.
מידע נוסף זמין בדוגמה הזו.
נפח אחסון מקומי מתמיד
נפח אחסון מתמיד מקומי מייצג דיסק מקומי שמצורף לצומת יחיד. אמצעי אחסון מקומיים קבועים מאפשרים לכם לשתף משאבי SSD מקומיים בין פודים. מכיוון שהדיסק המקומי הוא דיסק SSD מקומי, הנתונים עדיין זמניים.
אנחנו ממליצים על הגישה הזו אם אחד מהרכיבים הבאים פועל באשכול:
- עומסי עבודה שמשתמשים ב-StatefulSets וב-volumeClaimTemplates.
- עומסי עבודה שמשתפים מאגרי צמתים. אפשר להזמין כל נפח של Local SSD באמצעות PersistentVolumeClaim, ואין קידוד ישיר של HostPath ספציפי במפרט של ה-Pod.
- תאי אחסון שנדרש בהם כוח משיכה של נתונים לאותו SSD מקומי. תמיד מתוזמן פוד לאותו צומת כמו PersistentVolume המקומי שלו.
מידע נוסף זמין בדוגמה הזו ובמסמכי התיעוד של Kubernetes Volumes (כרכים) בקוד פתוח.
טיפול בתחזוקה של המארח
חלק מצמתי GKE שמשתמשים בכונני SSD מקומיים, כמו סוגי מכונות Z3 עם יותר מ-18TiB של כונני Titanium SSD מצורפים, לא תומכים במיגרציה פעילה במהלך תחזוקת המארח. במקום זאת, המכונה הווירטואלית נעצרת ומופעלת מחדש במקום. רשימה של משפחות מכונות עם התנהגויות ספציפיות במהלך אירועי תחזוקה מופיעה במאמר מידע על אירועים במארח במסמכי התיעוד של Compute Engine.
בגלל הפוטנציאל להשבתה ממושכת של צומת בסוגי מכונות שמבצעות הפעלה מחדש, מומלץ לתכנן את האפליקציות כך שיהיו עמידות, ולהתכונן למצב שבו יבוצע סיום של הפודים ותזמון מחדש שלהם בצמתים אחרים.
בדומה לצמתים עם יחידות GPU ו-TPU מצורפות, אתם יכולים להגדיר את האשכול כך שינהל את אירועי התחזוקה האלה בצורה חלקה. רכיב GKE maintenance-handler מזהה באופן אוטומטי תחזוקה קרובה בצמתים עם כונני SSD מקומיים. לפני שהתחזוקה מתחילה, המטפל מסמן את הצומת כדי למנוע תזמון של Pods חדשים, ואז מפנה בבטחה את ה-Pods הקיימים. כך אפשר לתזמן מחדש את ה-Pods בצמתים זמינים אחרים באשכול, בהתאם ל-PodDisruptionBudgets שהגדרתם.
הוראות מפורטות להגדרת עומסי העבודה כדי לנהל את האירועים האלה זמינות במאמר ניהול שיבושים בצמתים של GKE שלא מועברים בשידור חי.
הגבלות
האפליקציה צריכה לטפל בצורה תקינה במצב שבו אין יותר גישה לנתונים בכרכים של SSD מקומי. הנתונים שנכתבים לדיסק SSD מקומי לא נשמרים כשמוחקים את ה-Pod או הצומת, כשמתקנים או משדרגים אותם, או כשמתרחשת שגיאה שלא ניתן לשחזר.
הפרמטר 'אחסון זמני' Local SSD מגדיר את מחזור החיים של הנתונים בנפחי Local SSD על בסיס Pod, והפרמטר 'בלוק NVMe Local SSD' מגדיר את מחזור החיים של הנתונים בנפחי Local SSD על בסיס Node.
אם אתם צריכים אחסון קבוע, מומלץ להשתמש באפשרות אחסון עמידה (כמו Persistent Disk, Filestore או Cloud Storage). אפשר גם להשתמש בעותקים משוכפלים אזוריים כדי למזער את הסיכון לאובדן נתונים במהלך מחזור החיים של האשכול או של האפליקציה.
אי אפשר לשנות את הגדרות התצורה של SSD מקומי אחרי שיוצרים את מאגר הצמתים. אי אפשר להפעיל, להשבית או לעדכן את ההגדרה של כונן SSD מקומי עבור מאגר צמתים קיים. כדי לבצע שינויים, צריך למחוק את מאגר הצמתים וליצור מאגר חדש.
תאי Pod שמשתמשים ב-emptyDir משתמשים ב-SSD מקומי באופן שקוף. עם זאת, זה נכון לכל תאי ה-Pod בכל הצמתים במאגר הצמתים הזה. GKE לא תומך במצב שבו בחלק מה-Pods באותו מאגר צמתים נעשה שימוש בנפחי emptyDir של SSD מקומי שמגובים על ידי SSD מקומי, ובחלק מה-Pods נעשה שימוש בנפחי emptyDir שמגובים על ידי דיסק אתחול של צומת. אם יש לכם עומסי עבודה שמשתמשים בנפחי emptyDir שמגובים על ידי דיסק אתחול של צומת, כדאי לתזמן את עומסי העבודה במאגר צמתים אחר.
אשכולות Autopilot ואספקת צמתים אוטומטית תומכים רק בכונני SSD מקומיים באמצעות ComputeClasses בהתאמה אישית
מומלץ להשתמש ב-Local SSD כאחסון זמני עבור עומסי עבודה שפועלים במכונות וירטואליות שעברו אופטימיזציה לאחסון (Z3). מיגרציה פעילה נתמכת במכונות וירטואליות מסוג Z3 עם פחות מ-88 מעבדים וירטואליים, אבל מכונות וירטואליות מסוג Z3 עם 88 מעבדים וירטואליים או יותר מופסקות במהלך אירועי תחזוקה. מידע נוסף זמין במאמר בנושא חוויית תחזוקה למופעי Z3. מכיוון שמכונות וירטואליות מסוג Z3 עם 88 או יותר מעבדים וירטואליים מופסקות, יכול להיות שהנתונים ב-SSD המקומי של הצמתים לא יהיו זמינים במהלך אירועי תחזוקה, וששחזור הנתונים לא יתבצע אחרי התחזוקה. מידע נוסף זמין במאמר שמירת נתונים בדיסק אחרי סיום של מופע.
המאמרים הבאים
- איך מקצים נפח אחסון זמני שמגובה ב-SSD מקומי ומשתמשים בו
- איך מקצים נפח אחסון גולמי של בלוקים שמגובה ב-SSD מקומי ומשתמשים בו
- איך משתמשים בדיסקים לאחסון מתמיד ייעודיים כנפחים זמניים
- איך יוצרים נפחים
- איך משתמשים ב-CSI Driver של דיסק מתמשך ב-Compute Engine