מידעהצהרת נגישות
תצוגת צבעים באתר(* פועל בדפדפנים מתקדמים מסוג Chrome ו- Firefox)תצוגה רגילהמותאם לעיוורי צבעיםמותאם לכבדי ראייה
סגירה
sponsored by 

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

04/02/2021

מאת: אבי שוורץ, Account Executive ב-Dell Technologies ישראל

אתגרים בגיבוי וניהול המידע לסביבות קונטיינרים /K8s

תוך מספר שנים קונטיינרים (Container) שינו באופן דרמטי את הדרך בה מפתחים ומנהלים אפליקציות. מאמר זה בא להציע פתרון Enterprise Grade Level לגיבוי סביבות קונטיינרים. האתגרים שבניהול סביבות קונטיינרים בינוניות/גדולות דורשים מאיתנו חשיבה מחודשת על האופן בו אנו מנהלים את הסביבה ומגבים אותה. הפתרון שאסקור במאמר זה מאפשר שמירה על SLA ותנאי ה-Compliance של הארגון, שמירה מקסימאלית על המידע כנגד מחיקות, Corruption, הגנה כנגד איומי סייבר, ניהול המידע בין הסביבות השונות ועוד.

 

אז מה זה קונטיינרים?

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

הקונטיינר הוא יחידת תוכנה המכילה את כל הנדרש להפעלת היישום: האפליקציה/קוד עם כל התלויות שלה (Dependencies), ספריות מערכת וקונפיגורצייה. כך היישום יכול לפעול במהירות ובאמינות גם במעבר מסביבת מחשוב אחת לאחרת. אך זה לא הכל. לקונטיינרים יתרונות רבים נוספים על פני מכונות וירטואליות הנפוצות יותר. לרוב קונטיינר תופס נפח של כמה עשרות מגה בייט בעוד מכונה וירטואלית תופסת נפח של מספר ג'יגה בייט. אתחול של מכונה וירטואלית יכול לקחת מספר דקות בעוד את הקונטיינר ניתן לאתחל כמעט מיידית. כתוצאה מכך ניתן למחוק/להרים קונטיינר במהירות וכך לעשות שימוש יעיל יותר במשאבי השרת. יתרון נוסף הינו מודולריות. במקום להריץ אפלקיציה מורכבת בתוך קונטיינר אחד, ניתן לפצל את האפליקציה למודולים (כגון ה Data Base, Front End וכדומה). גישה זו נקראת מיקרו-שירותים (Microservices). אפליקציה הנבנית בשיטה זו קלה יותר לניהול מיכוון שכל מודול הוא פשוט יחסית, וניתן לבצע שינויים במודול ספציפי בלי לכתוב מחדש את כל האפליקציה. ומיכוון שכל קונטיינר תופס נפח מועט יחסית, ניתן להרים קונטיינר מייד רק כשהשירות נדרש.

הערך בשימוש בקונטיינרים-

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

האתגרים בעולם החדש-

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

כשיש 20 קונטיינרים ו 5 שירותים זה יחסית פשוט לניהול. אבל מה קורה כאשר ישנם 1000 קונטיינרים ומעל 400 שירותים? הניהול מתחיל להיות משימה מורכבת. לכן כשעובדים בקנה מידה בינוני/גדול הצורך באורקסטרציה של תהליכים נעשה הכרחי. אורקסטרציה בסביבות דינמיות גדולות מאפשר למנהלי הפיתוח והמתכנתים לשלוט בתהליכי הפיתוח, בדיקה והפריסה של השירותים.

ישנם מספר רב של תוכנות לאורקסטרציה של קונטיינרים- Kubernetes (K8s), RedHat OpenShift, Amazon EKS, Google GKE, Docker swarm ועוד. הנפוצה ביותר כיום הינה K8s.

אם נסתכל על צוות המפתחים, הם מעוניינים לשחרר גרסאות כמה שיותר מהר. צוותי הפיתוח פחות חשופים לאתגרים שמנהלי ה IT בארגון חשופים אליהם. לעומתם מנהלי ה IT רוצים לוודא שהאפליקציות, שצוות הפיתוח מעוניין לשחרר, עומדות בתנאי ה-Compliance וה-SLA של הארגון.

אתגרים בניהול ושמירת המידע בסביבת קונטיינרים-

Backup & Recovery ו Disaster Recovery- אתגר הראשון הינו גיבוי הקונטיינר, ההגנה על רכיבי Cluster K8s (DB, Pods, Secrets, Services, Configmaps...) -כיצד ניתן לשמור על המידע בסביבת Micro Services בצורה כזו שגם לאחר הורדת קונטיינר המידע לא נמחק? מה קורה למידע אם נפלה סביבה ואני רוצה להרימה מחדש? כיצד אני יכול לשמור על בסיס הנתונים במקרה של Corruption? האם אני יכול לבצע רפליקציה למידע?

 Data Management- אתגר שני נוגע לניהול המידע. האם אני יכול להעביר K8s Cluster מסביבת הייצור לענן הציבורי?

Value Added Services- אתגר שלישי נוגע לשירותי ערך מוסף. האם אני יכול למשל להגן על המידע כנגד מתקפות סייבר?

כאן נכנסת לתמונה פלטפורמת הגיבוי של Dell Technologies הנקראת Power Protect Data Manager (או בקיצור PPDM) המספקת מענה מלא לכל האתגרים הללו.

PPDM הינה פלטפורמת גיבוי יעילה אשר ממנפת את ההתפתחות האחרונה בארכיטקטורת הגיבוי של Dell Technologies. הפלטפורמה מספקת תפעול פשוט וגמישות מירבית ונבנתה כך שתוכל לספק מענה לגיבוי, ניהול ושחזור לסביבות 'רגילות' (VM, File, אורקל ועוד) אך גם לסביבות עליהן אנו דנים פה, ה- Next Generation Applications כקונטיינרים/K8s.

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

פלטפורמת הניהול של PPDM גמישה ומאפשרת לספק לצוות הפיתוח שירות Self Service. כך מפתחי האפליקציה יכולים לבצע גיבוי ושחזור בעצמם כאשר למנהל הגיבויים עדיין תהיה שליטה מלאה לוודא שמדיניות הגיבויים של המפתחים עומדת בתנאי ה-SLA וה-Compliance של הארגון. כך נוכל לענות על האתגר החשוב ביותר- צוות פיתוח שרוצה לשחרר גרסא כמה שיותר מהר ועדיין עומד בכל תנאי ה-Compliance של הארגון.

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

Power Protect Data Domain-

תוכנת PPDM מאפשרת גיבוי למערכות Power Protect Data Domain אשר, כמוצר משלים, מספק יתרונות רבים נוספים המספקים מענה לכל שאר האתגרים שציינתי:

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

אמינות המידע לאורך שנים- אחד הדברים החשובים ביותר בשימוש בפתרון הגנה על המידע הוא כמובן היכולת לשחזר את המידע ולוודא תקינותו לאורך שנים. מערכת Data Domain כוללת בתוכה מנגנון הנקרא DIA- Data Invulnerability Architecture- מנגנון זה פועל 100% מהזמן על 100% מהמידע (בטווח של כ 3 שבועות מתבצעת סריקה של כל המידע), ותפקידו לוודא כי המידע שנכתב תקין. במידה ויש Corruption המערכת מבצעת אחד מהשניים, תיקון המידע באופן עצמאי או דיווח למנהל המערכת. כך ניתן להגיע לרמת אמינות המידע הגבוהה ביותר הקיימת לאורך שנים. מצב זה למשל יכול למנוע אובדן מידע במצב בו הוחלף דיסק כתוצאה מעדכון Raid group.

חסכון בנפחים- כדי לאפשר שמירת מידע לאורך שנים, מערכת Data Domain מפעילה מספר רב של אלוגריתמים לדחיסה המספקים את יחס הדחיסה הטוב ביותר בעולם. יחס הדחיסה הסטטיסטי העולמי למערכות DD עומד על כ 65 ל 1.

שיפור בחלונות גיבוי – החסכון הגבוה בנפחים ושכבת דיסקי SSD מאפשרים שיפור משמעותי בזמני גיבוי ומהירות הגיבוי. יישום de-duplication בצד המקור מאפשר שימוש בקווי תקשורת רזים ביותר לביצוע הגיבוי. האפשרות לגבות רק שברירי מידע מאפשר לקצר זמני RPO באופן ניכר.

פרוטוקול DDBoost – פרוטוקול ייעודי הקיים במערכות Data Domain ומאפשר לגבות מידע ישירות למערך הגיבוי ללא הצורך במתווכי media server יקרים. בנוסף פרוטוקול זה מספק הקשחה חזקה מאוד ברמת התקשורת למערכות Data Domain כנגד מתקפות Ransomware.

רפליקציה- מובנית בין שתי מערכות data domain. שומר על יעילות החסכון בנפחים וכך ניתן להפחית בקווי התקשורת בין האתרים.

שחזור מהיר – השימוש בדיסק במערכות Data Domain מאפשר שימוש בתוכנת instant access כדי לקצר זמני RTO המאפשר למשל להריץ VM’s ישירות מעותק הגיבוי, בניגוד לצורך לשחזר את כל ה VM מעותק הגיבוי.

תמיכה בגיבוי לענן- תמיכה מלאה למטרת DR או LTR (long time retention)

Multi tenancy- הפרדה לוגית בין שכבות המידע בתוך מערכת Data Domain.

לסיכום-

המעבר לשימוש בקונטיינרים מציב אתגרים רבים בתחום ניהול ושמירת המידע. פלטפורמת PPDM של Dell Technologies מספקת פתרון תוכנה מקצה לקצה לכל סביבות הלקוח- from edge to core to cloud- כולל כמובן סביבות קונטיינרים. מדובר בפתרון Enterprise level אשר מסוגל לתפקד בסביבות המאתגרות ביותר ובשילוב יחד עם מערכות Data Domain Power Protect מספק ללקוח פתרון ארגוני רחב מכל הבחינות- גם תפעולי, גם אבטחתי, גם יעילות וחסכון ובעיקר עמידה ב SLA ובמטרות העסקיות של הארגון.