גיבוי עם Commvault: כמה סטטיסטיקות ומקרים

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

מערכת אחסון של מערכת גיבוי מבוססת Commvault במרכז הנתונים OST-2.

איך זה עובד?

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

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

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

בצד DataLine, נתונים מ-iData Agent מקבלים שרת סוכן מדיה ושולח אותו לאחסון במערכות אחסון, ספריות קלטות וכו'. כל זה מנוהל על ידי Commserve. בתצורה שלנו, שרת הבקרה הראשי ממוקם באתר OST, ושרת הגיבוי נמצא באתר NORD.

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

תכנית הפעולה של מערכת הגיבוי Commvault.

מערכת הגיבוי עובדת בעיקר על וירטואליזציה של VMware: שרתי CommServe, Media Agent ו-Proxy פרוסים על מכונות וירטואליות. אם הלקוח משתמש בציוד שלנו, הגיבויים ממוקמים במערכת האחסון Huawei OceanStor 5500 V3. כדי לגבות מערכות אחסון לקוח, אחסון גיבויים בספריות קלטות, נעשה שימוש בסוכני מדיה נפרדים בשרתים פיזיים.

מה חשוב ללקוחות?

מניסיוננו, לקוחות שבוחרים ב-Commvault לגיבוי שמים לב לנקודות הבאות.

לְנַחֵם. לקוחות רוצים לנהל גיבויים בעצמם. כל הפעולות הבסיסיות זמינות במסוף Commvault:

• הוספה והסרה של שרתים לגיבוי;
• הגדרת iData Agent;
• יצירה והתחלה ידנית של משימות;
• שחזור עצמי של גיבויים;
• הגדרת התראות לגבי מצב משימות הגיבוי;
• בידול של גישה לקונסולה בהתאם לתפקיד וקבוצת המשתמשים.

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

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

מניעת כפילויות בלוק כזה מבוססת על פונקציות גיבוב. לכל בלוק מוקצה hash, אשר מאוחסן בטבלת hash, מעין מסד נתונים (Deduplication Database, DDB). בעת העברת נתונים, ה-hash "מחורר" דרך הבסיס הזה. אם hash כזה כבר נמצא במסד הנתונים, אזי הבלוק מסומן כלא ייחודי ואינו מועבר לשרת ה-Media Agent (במקרה הראשון) או נכתב למערכת אחסון הנתונים (במקרה השני).

הודות למניעת כפילויות, אנו יכולים לחסוך עד 78% משטח האחסון. כעת 166,4 TB מאוחסן באחסון. ללא מניעת כפילויות, נצטרך לאחסן 744 TB.

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

הצפנה. אתה יכול להצפין נתונים בזמן הגיבוי באמצעות Commvault בדרכים הבאות:

• בצד סוכן הלקוח: במקרה זה, הנתונים יועברו למערכת הגיבוי כבר בצורה מוצפנת;
• בצד סוכני המדיה;
• ברמת הערוץ: הנתונים מוצפנים בצד סוכן הלקוח ומפוענחים בשרת ה-Media Agent.

אלגוריתמי הצפנה זמינים: Blowfish, GOST, Serpent, Twofish, 3-DES, AES (מומלץ על ידי Commvault).

כמה סטטיסטיקות

עד אמצע דצמבר, בעזרת Commvault, יש לנו 27 לקוחות שמגבים. רובם קמעונאים ומוסדות פיננסיים. הכמות הכוללת של נתוני העתקה מקוריים היא 65 TB.

מבוצעות כ-4400 משימות ביום. להלן נתונים סטטיסטיים על משימות שהושלמו ב-16 הימים האחרונים.

יותר מכל, מסדי נתונים של מערכת הקבצים של Windows, SQL Server ו-Exchange מגובים באמצעות Commvault.

ועכשיו המקרים המובטחים. למרות שהם לא אישיים (NDA אומר שלום :)), הם נותנים רעיון למה ואיך משתמשים בגיבוי מבוסס Commvault. להלן תיאורי מקרה עבור לקוחות המשתמשים במערכת גיבוי יחידה, כלומר תוכנות משותפות, שרתי Media Agent ומערכות אחסון.

תיק 1

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

משימה.ארגון גיבוי לבסיסי נתונים של Microsoft SQL, שרתי קבצים, שרתי אפליקציות, תיבות דואר של Exchange Online.

הנתונים הראשוניים ממוקמים במשרדים ברחבי רוסיה (יותר מ-10 ערים). עליך לבצע גיבוי לאתר DataLine עם שחזור נתונים לאחר מכן בכל אחד ממשרדי החברה.
במקביל, הלקוח רצה ניהול עצמי מלא עם בקרת גישה.
עומק אחסון - שנה. עבור Exchange Online, 3 חודשים עבור עותקים מקוונים ושנה עבור ארכיונים.

ההחלטה. עותק נוסף הוקם למאגרי המידע באתר השני: הגיבוי המלא האחרון של החודש מועבר לאתר אחר ונשמר בו למשך שנה.

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

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

תיק 2

צרכן. רשת חנויות למוצרי ילדים רוסית.
משימה. ארגון גיבוי עבור:
אשכול MS SQL טעון מאוד המבוסס על 4 שרתים פיזיים;
מכונות וירטואליות עם אתר אינטרנט, שרתי יישומים, 1C, Exchange ושרתי קבצים.
כל התשתית שצוינה של הלקוח מרווחת בין אתרי OST ו-NORD.
RPO לשרתי SQL - 30 דקות, לכל השאר - יום אחד.
עומק אחסון - משבועיים עד 2 יום, תלוי בסוג הנתונים.

ההחלטה. בחרנו בשילוב של פתרונות המבוססים על Veeam ו-Commvault. Veeam משמש לגיבוי קבצים מהענן שלנו. שרתי מסדי נתונים, Active Directory, דואר ושרתים פיזיים מגובים באמצעות Commvault.

כדי להשיג מהירות גיבוי גבוהה, הלקוח הקצה מתאם רשת נפרד בשרתים פיזיים עם MS SQL למשימות גיבוי. גיבוי מלא של מסד נתונים של 3,4 טרה-בתים לוקח שעתיים ו-2 דקות, ושחזור מלא לוקח 20 שעות ו-5 דקות.

ללקוח הייתה כמות גדולה של נתונים ראשוניים (כמעט 18 TB). אם הנתונים היו מוערמים על גבי ספריית קלטות, כפי שהלקוח עשה קודם לכן, יידרשו כמה עשרות מחסניות. זה יסבך את הניהול של כל מערכת הגיבוי של הלקוח. לכן, ביישום הסופי, ספריית הקלטות הוחלפה במערכת אחסון.

תיק 3

צרכן. רשת סופרמרקטים בחבר המדינות
משימה. הלקוח רצה לגבות ולשחזר מערכות SAP המתארחות בענן שלנו. עבור מסדי נתונים של SAP HANA RPO=15 דקות, עבור מכונות וירטואליות עם שרתי יישומים RPO=24 שעות. עומק אחסון - 30 יום. במקרה של תאונה RTO=1 שעה, לשחזור עותק לפי דרישה RTO=4 שעות.

ההחלטה. עבור מסד הנתונים HANA, גיבויים של קבצי DATA וקובצי יומן הוגדרו במרווחי זמן מוגדרים. קובצי יומן הועברו לארכיון כל 15 דקות או כשהם הגיעו לגודל מסוים.

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

גיבוי מלא של אחד ממסדי הנתונים של 181 ג'יגה-בייט נעשה תוך שעה ו-1 דקות.

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

ניהול הגיבוי זמין ללקוח גם דרך מסוף הלקוח הסטנדרטי של Commvault.

זה הכל להיום. שאל שאלות בתגובות.

מקור: www.habr.com