כונני 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, שכבות שניתנות לכתיבה בקונטיינר וקובצי אימג' שביחד מהווים את האחסון הזמני של הצומת, נמצאים ב-Local SSD. היתרונות כוללים רוחב פס משופר של קלט/פלט בהשוואה ל-Persistent Disk שמוגדר כברירת מחדל, וזמני הפעלה משופרים של Pod.
כשמשתמשים ב-SSD מקומי לאחסון זמני של צומת, אמצעי האחסון של ה-SSD המקומי של דיסק האתחול לא זמינים לשימושים אחרים. אל תשנו את התקני ה-SSD המקומיים, כמו /dev/nvme*, ישירות באמצעות Daemonset, HostPath או מנגנון אחר עם הרשאות, אחרת הצומת עלול להיכשל.
אם אתם צריכים שליטה מדויקת על אמצעי האחסון של ה-SSD המקומי, השתמשו בגישה של בלוק גולמי.
אחסון במכשיר לאחסון ולאחזור בלוקים
אחסון בהתקן בלוקים מאפשר גישה אקראית לנתונים בבלוקים בגודל קבוע. אפליקציות מסוימות דורשות גישה ישירה לאחסון של התקן הבלוקים, כי שכבת מערכת הקבצים מוסיפה תקורה מיותרת.
תרחישים נפוצים לשימוש באחסון של התקני בלוקים כוללים:
- מסדי נתונים שבהם הנתונים מאורגנים ישירות באחסון הבסיסי.
- תוכנה שמטמיעה בעצמה סוג כלשהו של שירות אחסון (מערכות אחסון מוגדרות-תוכנה).
בגרסה v1.25.3-gke.1800 של GKE ואילך, אפשר ליצור אשכולות ומאגרי צמתים עם כונני SSD מקומיים מסוג NVMe עם בלוקים גולמיים, באמצעות האפשרות --local-nvme-ssd-block. לאחר מכן תוכלו להתאים אישית את אחסון הבלוקים על ידי עיצוב מערכת קבצים לבחירתכם (כמו ZFS או HDFS) והגדרת RAID. האפשרות הזו מתאימה אם אתם צריכים שליטה נוספת כדי להריץ עומסי עבודה שדורשים גישה לאחסון בלוקים שמגובה ב-SSD מקומי.
אתם יכולים גם להשתמש בגישת הגישה לבלוקים עם Local SSD אם אתם רוצים מטמון נתונים מאוחד לשיתוף נתונים בין Pods, והנתונים קשורים למחזור החיים של הצומת. כדי לעשות את זה, מתקינים DaemonSet עם הגדרת RAID, מפרמטים מערכת קבצים ומשתמשים ב-PersistentVolume מקומי כדי לשתף נתונים בין Pods.
אחסון מעורב
בצמתים שבהם פועלת גרסה 1.37.0-gke.3570000 ואילך, אפשר לחלק למחיצות דיסקים של Local SSD באותו צומת כדי לספק גם אחסון זמני וגם אחסון גולמי של בלוקים. האחסון הזמני משמש לנפחי emptyDir ולספריות של סביבת זמן הריצה של הקונטיינר. כדי להגדיר את הגודל של מחיצת האחסון הזמני, משתמשים בהגדרה capacity של הדגל --ephemeral-storage-local-ssd.
כשמשלבים את שני סוגי האחסון בצומת אחד, אפשר להשתמש בתוויות הצומת שמשויכות גם לאחסון זמני וגם לאחסון בלוקים גולמי כדי לוודא שעומסי העבודה מתוזמנים כראוי:
cloud.google.com/gke-ephemeral-storage-local-ssd: "true"cloud.google.com/gke-local-nvme-ssd-partition: "true"
במאמר הקצאת כונני SSD מקומיים משולבים לאחסון בלוקים גולמיים ולאחסון זמני מוסבר איך להגדיר את קיבולת כונני ה-SSD המקומיים המשולבים ולהשתמש בהם.
דרישות המכונה
הדרך שבה מקצים כונני 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: עד 9 TiB. GKE מגדיר באופן אוטומטי את RAID מאחורי הקלעים. פורמט: מערכת קבצים (Kubernetes emptyDir) שילוב עם מתזמן Kubernetes: משולב באופן מלא כברירת מחדל. המתזמן של Kubernetes עוזר לוודא שיש מקום בצומת לפני ההצבה, ומשנה את קנה המידה של הצמתים לפי הצורך. במאמר הקצאה ושימוש באחסון זמני שמגובה ב-SSD מקומי מוסבר איך משתמשים בפרמטר הזה של ה-API. |
| בלוק SSD מקומי ב-NVMe | gcloud container clusters create |
v1.25.3-gke.1800 ואילך |
טכנולוגיית אחסון: NVMe הנתונים משותפים בין Pods: כן, באמצעות אמצעי אחסון מקומיים קבועים. מחזור החיים של הנתונים: צומת גודל והצורך בהגדרת RAID: עד 9 TiB. כדי להגדיר RAID בגדלים גדולים יותר, צריך לעשות את זה ידנית. פורמט: בלוק גולמי שילוב עם מתזמן Kubernetes: לא, כברירת מחדל. אתם צריכים לוודא שיש קיבולת בצמתים ולטפל בבעיות של שכנים רועשים. אם תצטרפו ל-PV מקומי, התזמון ישולב. כדי ללמוד איך להשתמש בפרמטר הזה של ה-API, קראו את המאמר הקצאה ושימוש באחסון בלוקים גולמיים שמגובה ב-SSD מקומי. |
תמיכה בפרמטרים קיימים של 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: עד 9 TiB. 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 מקומי
אפשר לגשת לנפחי 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 מחובר, לא תומכים במיגרציה פעילה במהלך תחזוקת המארח. במקום זאת, ה-VM נעצר ומופעל מחדש במקום. במאמר מידע על אירועים במארח שבמסמכי התיעוד של Compute Engine מפורטות משפחות המכונות שמתנהגות בצורה ספציפית במהלך אירועי תחזוקה.
בגלל האפשרות לזמן השבתה ממושך של צומת בסוגי מכונות שמופעלות מחדש, כדאי לתכנן את האפליקציות כך שיהיו עמידות, ולצפות לכך ש-Pods יופסקו ויתוזמנו מחדש בצמתים אחרים.
בדומה לצמתים עם GPUs ו-TPUs מצורפים, אתם יכולים להגדיר את האשכול כך שינהל את אירועי התחזוקה האלה בצורה חלקה. הרכיב 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 אחרי שיוצרים את מאגר הצמתים. אי אפשר להפעיל, להשבית או לעדכן את ההגדרה של ה-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 מקומי
- איך מקצים ומשתמשים בכונני SSD מקומיים משולבים לאחסון בלוקים גולמיים ולאחסון זמני
- איך משתמשים בדיסקים ייעודיים לאחסון מתמיד כנפחים זמניים
- איך יוצרים אמצעי אחסון
- איך משתמשים במנהל ההתקן של CSI לדיסק Persistent Disk של Compute Engine