Pritunl: מצב בקרה לעומת הפרופיל שנוצר

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

שני אובייקטים נראים כמו גיבויים ורק אחד משחזר את השירות

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

העתק של תצורת המארח חלקי באותה מידה. /etc/pritunl.conf מחזיק הגדרות ברמת המארח, כולל כיצד להגיע למסד הנתונים, ואינו מכיל את אובייקטי ה-VPN עצמם.

מה מחזיק מסד הנתונים ומה מחזיק המארח

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

המארח תורם קבוצה קטנה יותר אך בלתי ניתנת להעברה של ערכים. אחד מהם הוא /var/lib/pritunl/pritunl.uuid, הזהות של אותו צומת מסוים.

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

בצעו ייצוא עקבי, לא העתקת ספרייה

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

mongodump --uri="mongodb://127.0.0.1:27017/pritunl" --out=/var/backups/pritunl/db
sudo tar czf /var/backups/pritunl/host.tgz /etc/pritunl.conf /var/lib/pritunl/pritunl.uuid

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

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

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

mongorestore --uri="mongodb://127.0.0.1:27017" --drop /var/backups/pritunl/db
sudo tar xzf /var/backups/pritunl/host.tgz -C /

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

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