מידע על אחסון SSD מקומי ב-GKE

כונני 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 מקומי. היתרונות כוללים רוחב פס משופר של קלט/פלט בהשוואה ל-Persistent Disk שמוגדר כברירת מחדל, וזמני הפעלה משופרים של 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 אם רוצים מטמון נתונים מאוחד כדי לשתף נתונים בין Pod, והנתונים קשורים למחזור החיים של הצומת. כדי לעשות זאת, מתקינים DaemonSet עם הגדרת RAID, מעצבים מערכת קבצים ומשתמשים ב-PersistentVolume מקומי כדי לשתף נתונים בין Pods.

דרישות לגבי מכונות

הדרך להקצאת SSD מקומי לאשכולות GKE ולמאגרי הצמתים תלויה בסוג המכונה הבסיסי. ‫GKE תומך בנפחי SSD מקומיים בסדרות מכונות מהדור הראשון, השני והשלישי של Compute Engine. כדי להשתמש בנפחי SSD מקומיים נדרש סוג מכונה n1-standard-1 או גדול יותר. אין תמיכה בסוג המכונה שמוגדר כברירת מחדל, e2-medium. כדי לזהות את סדרת המכונות, משתמשים במספר בשם סוג המכונה. לדוגמה, מכונות N1 הן דור ראשון ומכונות N2 הן דור שני. רשימה של סדרות מכונות וסוגי מכונות זמינים מופיעה במאמר השוואה בין משפחות מכונות ומשאבים במאמרי העזרה של Compute Engine.

הדרישות של סדרות מכונות מהדור הראשון והשני

כדי להשתמש בסדרת מכונות מהדור הראשון או השני עם SSD מקומי, האשכול או מאגר הצמתים צריכים להריץ את GKE מגרסה 1.25.3-gke.1800 ואילך.

כדי להקצות נפח אחסון של SSD מקומי בסדרת מכונות מהדור הראשון או השני, מציינים את מספר נפחי האחסון של 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 מקומי. לא מציינים את מספר נפחי ה-SSD המקומיים שרוצים לכלול. במקום זאת, קיבולת ה-SSD המקומי שזמינה לאשכולות מוגדרת באופן מרומז כחלק מהצורה של מכונת ה-VM.

רשימה של סדרות מכונות ומספרים מקסימליים של SSD מקומיים שאפשר להשתמש בהם זמינה במאמר בחירת מספר תקין של SSD מקומיים במסמכי התיעוד של Compute Engine.

דפוס השימוש בנפחי אחסון של SSD מקומי

כדי להשתמש באמצעי אחסון מסוג Local SSD באשכולות, פועלים לפי השלבים הכלליים הבאים:

  1. הקצאת מאגר צמתים עם SSD מקומי מצורף: כדי ליצור מאגר צמתים ב-GKE עם SSD מקומי מצורף, מעבירים את הפרמטר של אחסון זמני או של אחסון בלוקים גולמי כשמפעילים את הפקודה create cluster. הגדרת הפרמטרים של Local SSD יוצרת מאגר צמתים של GKE עם Local SSD שמצורף ומוגדר כאחסון מקומי זמני או כאחסון בלוקים גולמי, בהתאם לפרמטרים שתבחרו. מידע נוסף על האפשרויות להקצאת SSD מקומי זמין במאמר פרמטרים של SSD מקומי.
  2. גישה לנתונים מכרכים של SSD מקומי: כדי להשתמש בנתונים מכרכים של SSD מקומי, אפשר להשתמש במבנה Kubernetes כמו emptyDir או כרך מקומי מתמשך. מידע נוסף על האפשרויות האלה זמין במאמר גישה ל-SSD מקומי.

פרמטרים של אחסון SSD מקומי ב-GKE

בטבלה הבאה מפורטים הפרמטרים המומלצים ש-GKE מספק להקצאת נפח אחסון של SSD מקומי באשכולות. אפשר להשתמש ב-CLI של gcloud כדי להעביר את הפרמטרים האלה.

סוג ה-SSD המקומי פקודה ב-CLI של gcloud זמינות GKE פרופיל SSD מקומי
אחסון זמני של SSD מקומי gcloud container clusters create
--ephemeral-storage-local-ssd		 ‫v1.25.3-gke.1800 ואילך

טכנולוגיית אחסון: NVMe

האם הנתונים משותפים בין קבוצות של שרתים: לא

מחזור חיים של נתונים: Pod

גודל וצורך בהגדרת RAID: עד 9TiB. ‫GKE מגדיר RAID באופן אוטומטי מתחת לפני השטח.

פורמט: מערכת קבצים (Kubernetes emptyDir)

שילוב של מתזמן Kubernetes: משולב באופן מלא כברירת מחדל. התזמן של Kubernetes יוודא שיש מקום בצומת לפני ההצבה, וישנה את קנה המידה של הצמתים אם צריך.

מידע נוסף על השימוש בפרמטר הזה של ה-API מופיע במאמר הקצאה ושימוש באחסון זמני שמגובה על ידי SSD מקומי.
בלוק NVMe SSD מקומי gcloud container clusters create
--local-nvme-ssd-block		 ‫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
--local-ssd-count

טכנולוגיית אחסון: SCSI

נתונים שמשותפים בין פודים: כן, באמצעות PV מקומיים

מחזור חיים של נתונים: צומת

גודל וצורך בהגדרת RAID: ‫375 GiB. צריך להגדיר RAID באופן ידני לגדלים גדולים יותר.

פורמט: מערכת קבצים (ext-4)

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

gcloud container clusters create
--ephemeral-storage-local-ssd
פרמטר של שטח אחסון זמני (בטא) gcloud beta container clusters create
--ephemeral-storage

טכנולוגיית אחסון: NVMe

האם הנתונים משותפים בין קבוצות: לא

מחזור חיים של נתונים: Pod

גודל והצורך בהגדרת RAID: עד 9TiB. ‫GKE מגדיר RAID באופן אוטומטי מתחת לפני השטח.

פורמט: מערכת קבצים (Kubernetes emptyDir)

שילוב של מתזמן Kubernetes: משולב באופן מלא כברירת מחדל. מתזמן Kubernetes יוודא שיש מקום בצמתים לפני ההצבה, וישנה את קנה המידה של הצמתים אם צריך.

gcloud container clusters create
--ephemeral-storage-local-ssd
פרמטר של נפחי אחסון SSD מקומיים (אלפא) gcloud alpha container clusters create
--local-ssd-volumes

טכנולוגיית אחסון: NVMe או SCSI

האם הנתונים משותפים בין קבוצות: לא

מחזור חיים של נתונים: צומת

גודל והצורך בהגדרת RAID:

‫375 GiB. צריך להגדיר RAID באופן ידני לגדלים גדולים יותר.

פורמט: מערכת קבצים (ext-4) או בלוק גולמי

שילוב של מתזמן Kubernetes: לא כברירת מחדל. צריך לוודא שיש קיבולת בצמתים ולטפל בבעיית השכנים הרועשים.

gcloud container clusters create
--local-nvme-ssd-block

גישה ל-SSD מקומי

אפשר לגשת לנפחי Local SSD באחת מהשיטות הבאות.

נפח emptyDir

ב-GKE מגרסה v1.25.3-gke.1800 ואילך, אפשר להשתמש באחסון זמני כנפח emptyDir שמגובה על ידי Local SSD, באמצעות האפשרות --ephemeral-storage-local-ssd. מומלץ להשתמש בגישה הזו ברוב המקרים, כולל באפליקציות שזקוקות לשטח אחסון זמני וזמני לביצועים גבוהים.

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

מידע נוסף זמין בדוגמה הזו.

נפח אחסון מתמיד מקומי

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

אנחנו ממליצים על הגישה הזו אם אחד מהרכיבים הבאים פועל באשכול:

  • עומסי עבודה שמשתמשים ב-StatefulSets וב-volumeClaimTemplates.
  • עומסי עבודה שמשתפים מאגרי צמתים. אפשר להזמין כל נפח של Local SSD דרך PersistentVolumeClaim, ואין קידוד ישיר של HostPath ספציפי במפרט של ה-Pod.
  • תאי שרת שנדרשת בהם כוח משיכה של נתונים לאותו SSD מקומי. תמיד מתוזמן פוד לאותו צומת כמו PersistentVolume המקומי שלו.

מידע נוסף זמין בדוגמה הזו ובמסמכי התיעוד של Kubernetes Volumes (כרכים) בקוד פתוח.

טיפול בתחזוקה של המארח

חלק מצמתי GKE שמשתמשים בכונני SSD מקומיים, כמו סוגי מכונות Z3 עם יותר מ-18TiB של כונני Titanium SSD מצורפים, לא תומכים במיגרציה פעילה במהלך תחזוקת המארח. במקום זאת, המכונה הווירטואלית מפסיקה ומופעלת מחדש במקום. רשימה של משפחות מכונות עם התנהגויות ספציפיות במהלך אירועי תחזוקה מופיעה במאמר מידע על אירועים במארח במסמכי התיעוד של Compute Engine.

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

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

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

הגבלות

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

    הפרמטר ephemeral storage Local SSD מגדיר את מחזורי החיים של הנתונים בנפחי ה-SSD המקומיים על בסיס Pod, והפרמטר NVMe Local SSD block מגדיר את מחזורי החיים של הנתונים בנפחי ה-SSD המקומיים על בסיס Node.

    אם אתם צריכים אחסון קבוע, מומלץ להשתמש באפשרות אחסון עמידה (כמו Persistent Disk,‏ Filestore או Cloud Storage). אפשר גם להשתמש בעותקים משוכפלים אזוריים כדי למזער את הסיכון לאובדן נתונים במהלך מחזור החיים של האשכול או של פעולות מחזור החיים של האפליקציה.

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

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

  • אשכולות Autopilot ואספקת צמתים אוטומטית תומכים רק בכונני SSD מקומיים באמצעות ComputeClasses בהתאמה אישית.

  • מומלץ להשתמש ב-Local SSD כאחסון זמני לעומסי עבודה שפועלים במכונות וירטואליות שעברו אופטימיזציה לאחסון (Z3). מיגרציה פעילה נתמכת במכונות וירטואליות מסוג Z3 עם פחות מ-88 מעבדים וירטואליים, אבל מכונות וירטואליות מסוג Z3 עם 88 מעבדים וירטואליים או יותר מופסקות במהלך אירועי תחזוקה. מידע נוסף מופיע במאמר בנושא חוויית תחזוקה למופעי Z3. מכיוון שמכונות וירטואליות מסוג Z3 עם 88 או יותר מעבדים וירטואליים מופסקות, יכול להיות שהנתונים ב-SSD המקומי של הצמתים לא יהיו זמינים במהלך אירועי תחזוקה, וששחזור הנתונים לא יתאפשר אחרי התחזוקה. מידע נוסף זמין במאמר שמירת נתונים בדיסק אחרי סיום של מופע.

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