איך לנהל מידע בסביבות מבוססות קונטיינרים?

מהפכת הקונטיינרים הביאה איתה לא מעט שינויים בדרך שבה אנחנו כותבים קוד ומתנהלים; אבל למרות הכל, המידע תמיד היה ונשאר חיוני. כך ננהל אותו בחוכמה

מקור: Pixabay

מאת: מיקי שאול

בשנים האחרונות Containers (קונטיינרים וירטואליים), ובראשם Docker Containers, הפכו לכלי המרכזי לפריסה (Deployment) של אפליקציות בארגונים, זאת בעיקר בזכות הפשטות הרבה שהביאו איתם. האפליקציות עצמן יכולות להיות חדשות – כאלו שתוכננו ונבנו מאפס לסביבה מסוג זה, וקיימות – כאלו שהותאמו לפרדיגמות החדשות ולכלים החדשים.

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

בשנים האחרונות Docker וסביבות ה-Container Orchestration השונות, כגון Kubernetes ו-Swarm, הבינו את הנקודה הזו והן משקיעות בפיתוח רב סביב נושא אחסון וניהול המידע בסביבה מבוססת Containers. שינויים מרכזיים שניתן לראות בשנים האחרונות:

  • שינוי הפרדיגמה וניתוק האחסון מה-Docker Container (שתי ישויות נפרדות במערכת)
  • תמיכה של Docker ב-Volume Plugins ואינטגרציה לפתרונות חיצוניים לניהול מידע
  • הצגה של Dynamic Storage Provisioning ב-Kubernetes והאפשרות לנהל Storage דרך Storage Class-ים עם אינטגרציה ל-Provisioner חיצוני
  • הכנסה של Resource Quota על Storage ב-Kubernetes דבר המאפשר לנו לנהל אותו כמו כל שאר המשאבים במערכת עם שליטה והגבלות
  • כתיבה של CSI (Container Storage Interface) חדש כדי לאפשר ממשק כללי לניהול Storage בדומה לממש שקיים היום לעולמות ה-Network (CNI)

שאלה שעשויה לעלות כאשר מדובר בשימוש ב-Storage עם Container-ים היא האם נכון בכלל לעשות כך? הרי Container-ים במקור יועדו עבור מערכות שהן Ephemeral (שלא שומרות State), אז למה בכלל להשתמש בהם עבור מערכות שכן שומרות State? מה היתרונות בשימוש ב-Container-ים במערכות מסוג זה?

היתרון המרכזי שמביאים איתם Container-ים הוא אריזה סטנדרטית וקלות פריסה. בנוסף גם קלות רבה בשדרוגים וניהול גרסאות של מערכות. יתרונות אלו יכולים להיות שימושיים מאד בניהול DB-ים ושירותים ששומרים State במיוחד בסביבות בדיקות, QA, ATP. ערך מוסף גדול יותר ניתן לקבל כאשר אנו יוצרים אינטגרציה ומשתמשים בכלים של סביבות Container Orchestration וכלים של חברות צד שלישי המספקות ממשקי ניהול אחסון לסביבות אלו. אינטגרציה זו מאפשר לנו להשתמש בכלים כמו Snapshot/ThinClone ביחד עם StatefulSet (ראו פירוט בהמשך) כדי לשכפל סביבות ו-Cluster-ים שלמים של DB-ים על כל המידע וההגדרות שלהן בפקודה בודדת ולקבל סביבה זמינה תוך מספר שניות. פונקציה זו יכולה להיות שימושית מאד כדי לגבות DB-ים לפני שדרוגים בסביבות Prod או לשכפל DB-ים לסביבות ATP כדי לבצע בדיקות עומסים לדוגמה.

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

הגדרת משאבי אחסון ב-K8s

כאשר אני מגדירים אחסון ב-K8s אנחנו צריכים להגדיר אותו בשני שלבים.

בשלב הראשון אנחנו צריכים לקשר את האחסון הפיזי להגדרה ב -K8s. להגדיר מול איזה סוג אחסון אנחנו רוצים לעבוד (לדוגמא נתיב מקומי, מערכת אחסון מרכזי, שירותי NFS וכד׳), מה צורת הגישה ופרמטרים נוספים. כל ההגדרות האלו נעשות על ידי הגדרה של ישות בשם Persistent Volume או PV (ראו דוגמה 1).

השלב השני מגיע כאשר יש דרישה אפליקטיבית לצריכת אחסון ובו אנו מקשרים בין האפליקציה שיכולה להיות Pod בודד או StatefulSet לדוגמה, להגדרת אחסון פיזי (PV) קיימת. הגדרה זו נעשית על ידי הגדרה של ישות בשם Persistent Volume Claim (PVC) (ראו דוגמה 2)

דוגמה 1: הגדרה של Persistent Volume בנפח של 1GB על גבי AWS EBS

 

דוגמה 2: הגדרה של Persistent Volume Claim בנפח של 1GB

 

הגדרת אפליקציה הצורכת שירותי אחסון – StatefulSet

כאשר מגדירים שירותים ואפליקציות ב-K8s מסוג Stateless אנו משתמשים ב-Controllers מסוג ReplicaSet ו-Deployment, כדי לנהל את הפריסה של האפליקציה על גבי ה-K8s Cluster, את השרידות שלה, את הגרסאות שלה ואת אסטרטגיית השדרוג שלה. אך כאשר מדובר בשירותים או אפליקציות מסוג Stateful, אשר נדרש שישמרו מידע מעבר לחיי השירות הבודד אנו צריכים להגדיר Controller עם מאפיינים מיוחדים בשם StatefulSet. Controller מסוג זה מאפשר:

  • שמות ייחודיים וקבועים ל-Pod השונים על פי מספר סידורי עולה לדוגמה database-0, database-1 וכו׳ (בשונה מ-ReplicaSet המקבלים שם אקראי)
  • הגדרת אחסון בלעדי לכל Pod המנוהל ע״י ה-Controller על ידי volumeClaimTemplates (בדומה ל-PVC)
  • יצירת הPod-ים נעשית בצורה הדרגתית ועל פי מספור סידורי עולה. היצירה של ה-Pod נעשית רק בתנאי שה-Pod הקודם תקין. התנהגות זו נכונה גם לגבי הרחבת השירות (Scale up)
  • מחיקת ה-Pod-ים נעשית באופן מדורג מהמספר הגבוה לנמוך. התנהגות זו נכונה לגם לגבי צמצום השירות (Scale Down).

תכונות ומאפיינים אלו מאפשרים ניהול של מערכות כמו מסדי נתונים מעבר לחיי השירות הבודד. ניתן לראות הגדרה כזו בדוגמה 3. בדוגמה ניתן לראות הגדרה של StatefulSet של ModgoDB המורכב מ-3 עותקים המנהלים רפליקציה בינם לבין עצמם. לכל עותק מוגדר שטח אחסון ייעודי של 100GB על ידי volumeClaimTemplates.

הגדרות אחסון סטטיות והגדרות דינאמיות

כאשר אנו עובדים בשיטת הקצאה סטטית, אנחנו צריכים לבצע את כל ההגדרות הפיזיות (PV) לפני שאנחנו יוצרים את הדרישה האפליקטיבית (PVC). אם שכחנו לייצור משהו בהגדרות הפיזיות (PV) הנדרשות לאפליקציה, הבקשה של האפליקציה תכשל.

לדוגמה אנו רוצים ליצור StatefulSet עם שירות MongoDB, השירות יהיה מורכב בשלב הראשון משישה מופעים של Container הבסיס שלנו (זה של MongoDB) וכל מופע כזה ידרוש חיבור לאחסון בנפח של 250GB, כלומר PVC עבור PV בגודל של 250GB. במצב כזה אם לא דאגנו מראש להגדרות של שישה PV בגודל של לפחות 250GB כל אחד הבקשה תכשל.

כאשר אנו עובדים בשיטת הקצאה דינאמית אין צורך לבצע את כל ההגדרות הפיזיות מראש (PV). ההגדרות יתבצעו באופן דינמי כאשר תעלה דרישה מסוימת (PVC) מהאפליקציה. בשיטה זו קיים מתווך בשם Dynamic Storage Provisioner, אשר מבצע את כל העבודה של הגדרת האחסון הפיזי באופן אוטומטי. אבל איך פונים למתווך הזה בזמן הגדרת הדרישה שלנו לאחסון (PVC) ואיך הוא ידע מה הפרמטרים או הסטנדרטים שאנו רוצים להגדיר באחסון הפיזי (PV)? לשם כך נשתמש בישות נוספת בשם Storage Class (SC).

הגדרות ה-SC כוללות בעיקר את שם המתווך שלנו או provisioner (לדוגמה AWS EBS או AzureDisk). את הפרמטרים שאנו רוצים להעביר למתווך או parameters (לדוגמה סוג הדיסק או אופן ה-mount לשרת). אנחנו יכולים החזיק SC רבים אשר פונים למתווכים שונים עם פרמטרים שונים כל אחד (ראו דוגמה 3)

דוגמה 3: הגדרה של StorageClass עבור AWS EBS

 

דוגמה 4: הגדרה של StatefulSet של MongoDB עם 3 עותקים

 

הכותב הינו מהנדס מערכות בנטאפ ישראל

כתב אורח

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

הגב

1 תגובה על "איך לנהל מידע בסביבות מבוססות קונטיינרים?"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

* שימו לב: תגובות הכוללות מידע המפר את תנאי השימוש של Geektime, לרבות דברי הסתה, הוצאת דיבה וסגנון החורג מהטעם הטוב ו/או בניגוד לדין ימחקו. Geektime מחויבת לחופש הביטוי, אך לא פחות מכך לכללי דיון הולם, אתיקה, כבוד האדם והדין הישראלי.

סידור לפי:   חדש | ישן | הכי מדורגים
יאיר
Guest

סתם שאלה.. מי שבוחר לכם את התמונה של הכתבה זה רובוט? ;-)

wpDiscuz

תגיות לכתבה: