כיצד GitLab עוזרת לך לגבות אחסון גדול של NextCloud

היי הבר!

היום אני רוצה לדבר על הניסיון שלנו באוטומציה של גיבוי נתונים גדולים ממחסני Nextcloud בתצורות שונות. אני עובד כתחנת שירות ב-Molniya AK, שם אנחנו עושים ניהול תצורה של מערכות IT; Nextcloud משמש לאחסון נתונים. כולל, עם מבנה מבוזר, עם יתירות.

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

פרהיסטוריה

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

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

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

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

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

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

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

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

כלי גיבוי

התחלנו את החיפוש אחר שיטות פתרון על ידי בחירת כלי ליצירת גיבוי.

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

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

ניהול גיבויים

Borg ורסטיק טובים, אבל לאף אחד מהמוצרים אין מנגנון בקרה ריכוזי. לצורך ניהול ובקרה בחרנו בכלי שכבר הטמענו, שבלעדיו לא נוכל לדמיין את עבודתנו, כולל אוטומציה - זהו ה-CI/CD המוכר - GitLab.

הרעיון הוא כדלקמן: gitlab-runner מותקן בכל צומת המאחסן נתוני Nextcloud. הרץ מריץ סקריפט בלוח זמנים שמנטר את תהליך הגיבוי, והוא משיק את Borg או Restic.

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

כאן כאן ב-GitHub פרסמנו דוגמאות של הסקריפט עבור משימות שונות, ובסופו של דבר צירפנו אותו לגיבוי של לא רק Nextcloud, אלא גם שירותים רבים אחרים. יש שם גם מתזמן אם אתה לא רוצה להגדיר אותו ידנית (ואנחנו לא רוצים) ו-.gitlab-ci.yml

אין עדיין דרך לשנות את פסק הזמן של CI/CD ב-Gitlab API, אבל הוא קטן. צריך להגדיל אותו, נניח 1d.

GitLab, למרבה המזל, יכולה להשיק לא רק לפי commit, אלא רק לפי לוח זמנים, זה בדיוק מה שאנחנו צריכים.

עכשיו לגבי תסריט העטיפה.

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

• יש להפעיל אותו הן על ידי הרץ והן ביד מהקונסולה עם אותה פונקציונליות.
• חייבים להיות מטפלי שגיאות:
• קוד החזרה.
• חפש מחרוזת ביומן. לדוגמה, עבורנו שגיאה עשויה להיות הודעה שהתוכנית אינה מחשיבה כאטלנית.
• זמן קצוב לעיבוד. זמן ההובלה חייב להיות סביר.
• אנחנו צריכים יומן מפורט מאוד. אבל רק במקרה של טעות.
• כמו כן, מתבצעות מספר בדיקות לפני תחילת העבודה.
• בונוסים קטנים לנוחות שמצאנו שימושיים במהלך תהליך התמיכה:
• ההתחלה והסוף נרשמים ב-syslog של המחשב המקומי. זה עוזר לחבר שגיאות מערכת ופעולת גיבוי.
• חלק מיומן השגיאות, אם קיים, יוצא ל-stdout, כל היומן נכתב לקובץ נפרד. זה נוח להסתכל מיד על CI ולהעריך את השגיאה אם ​​היא טריוויאלית.
• מצבי ניפוי באגים.

היומן המלא נשמר כחפץ ב- GitLab; אם אין שגיאה, היומן נמחק. אנחנו כותבים את התסריט ב-bash.

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

אֵיך מַפעִילִים אֶת זֶה

רץ עם מפעל Bash מופעל בצומת הגיבוי. לפי המתזמן, עבודה CI/CD מושקת בלפת מיוחדת. הרץ משיק סקריפט עטיפה אוניברסלי למשימות כאלה, הוא בודק את תקפות מאגר הגיבוי, נקודות הרכבה וכל מה שאנחנו רוצים, ואז מגבה ומנקה את הישן. הגיבוי המוגמר עצמו נשלח ל-S3.

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

לא השתמשנו בתכונה של שליחת גיבוי באמצעות ssh. זה לא מוסיף אבטחה, ויכולות הרשת של ספק ה-S3 גבוהות בהרבה ממכונת ה-ssh האחת שלנו.

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

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

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

Readme ברוסית

פונקציות עיקריות

• prepare הכנה
• testcheck בדיקת מוכנות
• maincommand צוות ליבה
• forcepostscript פונקציה שמתבצעת בסופו של דבר או בטעות. אנו משתמשים בו כדי לבטל את טעינת המחיצה.

פונקציות שירות

• cleanup אנו מתעדים שגיאות או מוחקים את קובץ היומן.
• checklog נתח את היומן עבור התרחשות של שורה עם שגיאה.
• ret מטפל ביציאה.
• checktimeout לבדוק פסק זמן.

סביבה

• VERBOSE=1 אנו מציגים שגיאות על המסך באופן מיידי (stdout).
• SAVELOGSONSUCCES=1 לשמור את היומן עם הצלחה.
• INIT_REPO_IF_NOT_EXIST=1 צור מאגר אם הוא לא קיים. מושבת כברירת מחדל.
• TIMEOUT זמן מקסימלי לפעולה הראשית. אתה יכול להגדיר את זה בתור 'm', 'h' או 'd' בסוף.

מצב אחסון עבור עותקים ישנים. בְּרִירַת מֶחדָל:

• KEEP_DAILY=7
• KEEP_WEEKLY=4
• KEEP_MONTHLY=6

משתנים בתוך הסקריפט

• ERROR_STRING — מחרוזת עבור יומן הצ'ק אין לשגיאה.
• EXTRACT_ERROR_STRING - ביטוי עבור הצג מחרוזת אם שגיאה.
• KILL_TIMEOUT_SIGNAL - אות להרג אם פסק זמן.
• TAIL - כמה מחרוזות עם שגיאות על המסך.
• COLORMSG - צבע ההודעה (צהוב ברירת מחדל).

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

רסטיק נגד בורג

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

קריטריוני הבחירה שלנו, בנוסף לאלו שכבר צוינו (מניעת כפילויות, החלמה מהירה וכו'):

• התנגדות לעבודה לא גמורה. בדוק להרוג -9.
• גודל בדיסק.
• דרישה למשאבים (מעבד, זיכרון).
• גודל כתמים מאוחסנים.
• עבודה עם S3.
• בדיקת תקינות.

לבדיקה, לקחנו לקוח אחד עם נתונים אמיתיים וגודל כולל של 1,6 TB.
תנאים.

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

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

כדי להפחית את השפעת הרשת, השתמשנו בספק מקומי - Yandex Cloud.

תוצאות בדיקות השוואה.

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

גיבוי
גודל

בורג
562Gb

קשור
628Gb

• לפי מעבד
  בורג עצמו צורך מעט, עם דחיסת ברירת מחדל, אבל יש להעריך את זה יחד עם תהליך המטומטם. בסך הכל, הם ברי השוואה ומשתמשים בכ-1,2 ליבות באותה מכונה וירטואלית לבדיקה.
• זיכרון. רסטיק הוא כ-0,5GB, Borg הוא כ-200MB. אבל כל זה לא משמעותי בהשוואה למטמון קבצי המערכת. לכן רצוי להקצות יותר זיכרון.
• ההבדל בגודל הכתם היה בולט.

גיבוי
גודל

בורג
בערך 500MB

קשור
בערך 5MB

• חווית ה-S3 של רסטיק מעולה. עבודה עם Borg דרך goofys לא מעלה שאלות, אך צוין שמומלץ לבצע umount לאחר השלמת הגיבוי כדי לאפס לחלוטין את המטמון. הייחודיות של S3 היא שחלקים שאובים לא יישלחו לעולם לא יישלחו לדלי, מה שאומר שמידע שלא מלאו באופן מלא מוביל לנזק גדול.
• בדיקת התקינות עובדת היטב בשני המקרים, אך המהירות שונה משמעותית.
  רסטי שעות 3,5.
  Borg, עם מטמון קבצי SSD של 100GB - שעות 5תוצאה של אותה מהירות בערך אם הנתונים נמצאים בדיסק מקומי.
  Borg קורא ישירות מ-S3 ללא מטמון שעות 33. ארוך בצורה מפלצתית.

השורה התחתונה היא שבורג יכול לדחוס ויש לו כתמים גדולים יותר - מה שהופך את פעולות האחסון ו-GET/PUT ב-S3 לזולות יותר. אבל זה בא במחיר של אימות מורכב ואיטי יותר. באשר למהירות ההתאוששות, לא הבחנו בהבדל. Restic לוקח את הגיבויים הבאים (אחרי הראשון) קצת יותר זמן, אבל לא באופן משמעותי.

אחרון חביב בבחירה היה גודל הקהילה.

ובחרנו בבורג.

כמה מילים על דחיסה

לבורג יש אלגוריתם דחיסה חדש מצוין בארסנל שלו - zstd. איכות הדחיסה אינה גרועה מ-gzip, אבל הרבה יותר מהירה. וניתן להשוות במהירות לברירת המחדל lz4.

לדוגמה, dump של מסד נתונים של MySQL נדחס פי שניים יותר מאשר lz4 באותה מהירות. עם זאת, ניסיון עם נתונים אמיתיים מראה שיש הבדל קטן מאוד ביחס הדחיסה של צומת Nextcloud.

לבורג יש מצב דחיסה בונוס למדי - אם לקובץ יש אנטרופיה גבוהה, אז הדחיסה לא מוחלת כלל, מה שמגביר את המהירות. מופעל על ידי אפשרות בעת יצירה
-C auto,zstd
עבור אלגוריתם zstd
אז עם האפשרות הזו, בהשוואה לדחיסת ברירת המחדל, קיבלנו
560Gb ו-562Gb בהתאמה. הנתונים מהדוגמה למעלה, להזכירכם, ללא דחיסה התוצאה היא 628Gb. התוצאה של הפרש של 2GB קצת הפתיעה אותנו, אבל חשבנו שבכל זאת נבחר בה. auto,zstd.

שיטת אימות גיבוי

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

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

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

מדרגיות מושגת על ידי הפעלת רצים בצמתים שונים עם תגים שונים.
הניטור שלנו אוסף סטטוסי גיבוי דרך ה-API של GitLab בחלון אחד; במידת הצורך, ניתן להבחין בבעיות בקלות ובקלות להתמקם.

מסקנה

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

מקור: www.habr.com