יש להכין ולבדוק את השרת החדש תחילה, להעתיק נתונים בשיטת עקביות נתמכת על ידי האפליקציה, להגדיר חלון מעבר ולשמר את הסביבה הישנה. החזרה לאחור חייבת להתחשב בכתיבות שהתקבלו בשרת החדש, ולא רק בשינוי DNS.
יש למפות את השירות לפני העברת המכונה
מעבר כולל יותר מקבצי האפליקציה. יש לרשום מסדי נתונים, העלאות, משימות מתוזמנות, עובדי תור, אישורים, דומיינים, סודות ואינטגרציות יוצאות. יש לתעד גרסאות תוכנה ואת הנחות התפעול החשובות, כמו הרשאות קבצים ונתיבי אחסון. שרת ייעודי חדש עשוי לחשוף תלות נשכחת שהותקנה בשקט לפני שנים בסביבה הישנה.
יש להקצות בעלים להחלטת המעבר ולהגדיר איך נראית הצלחה. יש לכלול בדיקות גלויות למשתמש, עקביות נתונים ויכולת לשחזר גישה. יש לאשר שהתצורה החדשה נמסרה ושמישה לפני הכרזה על מועד מעבר. אישור הזמנה או מפרט חומרה ברשימה אינם זהים ליעד עובד שמוכן לקבל נתוני ייצור.
יש לבנות את היעד כסביבה נפרדת
יש להתקין את מחסנית התוכנה הנדרשת, לקבוע ניהול ולהגדיר את חומת האש המיועדת. יש לשמור סודות באופן פרטי ולהגדיר הרשאות שירות במכוון. יש לאמת את שם המארח והתנהגות האישור שהאפליקציה מצפה להם לפני שתעבור תעבורה ציבורית. התיעוד של Apache על מארחים וירטואליים ממחיש מדוע ניתוב לפי שם מארח הוא החלטת תצורה נפרדת מכתובת השרת. עמוד ברירת מחדל שעובד אינו מוכיח שמארח האפליקציה הנכון מוגדר.
יש להשתמש בערכת נתונים משוחזרת מייצגת לתרגול, כאשר דואר יוצא, תשלומים ומשימות מתוזמנות מושבתים או מנותבים למערכות בדיקה בטוחות. זה מונע מסביבת הבדיקה לפעול על משתמשים אמיתיים. יש לתרגל התחברות, העלאות, עבודת רקע ושחזור. יש לתעד את הנוהל ומשכו כך שהחלון האמיתי יתבסס על תהליך נצפה ולא על אופטימיות.
יש לבחור גבול נתונים עקבי
יש להשתמש בשיטת גיבוי או שכפול שנתמכת על ידי מסד הנתונים והאפליקציה. PostgreSQL מבדיל בין dump של SQL, גיבויי מערכת קבצים וארכיון רציף, שלכל אחד מהם הנחות משלו. ההנחיות שלו ל-dump מציינות ש-dump של מסד נתונים יכול להיות עקבי פנימית בעוד שתפקידים ברמת האשכול ופרטים אחרים דורשים טיפול נפרד. יש לקרוא את הדרישות עבור המערכת המדויקת שאתה מפעיל במקום להעתיק קבצי נתונים פתוחים ללא הבחנה.
יש לתכנן כיצד מסד הנתונים מתייחס להעלאות ולמצב התור. אם רשומה מצביעה על קובץ שהועתק בזמן אחר, האפליקציה המשוחזרת יכולה להיות חלקית גם אם שתי ההעתקות הצליחו בנפרד. יש להחליט אם להשהות כתיבות לזמן קצר, להשתמש בהסדר שכפול נבדק או לבצע ייצוא ייעודי לאפליקציה. יש לשמור את החלטת העקביות הזו מפורשת במדריך.
| שלב | ראיות נדרשות | החלטה |
|---|---|---|
| תרגול | האפליקציה והנתונים המשוחזרים עוברים בדיקות | היעד יכול להישקל למעבר |
| סנכרון סופי | נקודת שחזור עקבית מוגדרת | יש להמשיך רק עם שינויים שיוריים מובנים |
| החלפת תעבורה | ניתוב נכון והתנהגות אישור נכונה | יש לנטר את שני היעדים |
| חזרה לאחור | מיקום כל הכתיבות החדשות שהתקבלו | יש להתאים נתונים לפני החזרת התעבורה |
יש להכין ניתוב תעבורה בלי להבטיח שינויים מיידיים
DNS time-to-live קובע כמה זמן רשומות עשויות להישמר במטמון, כפי שמוסבר בתיעוד DNS של Cloudflare. יש לבדוק את ה-TTL מוקדם אם DNS הוא חלק מהמעבר, ולאפשר לרשומות קיימות במטמון להתיישן תחת ההגדרה הקודמת שלהן. שינוי הערך ברגע המעבר לא יכול לקצר בדיעבד כל תשובה שנשמרה במטמון. לקוחות שונים עשויים להגיע ליעדים שונים במהלך המעבר.
יש להשאיר את הסביבה הישנה זמינה בזמן ששינויי הניתוב מתבססים, עם מדיניות מכוונת בשאלה אם היא עדיין יכולה לקבל כתיבות. יש להימנע מהרצת צרכני תור או משימות מתוזמנות כפולים אלא אם האפליקציה תוכננה לכך. יש לנטר בקשות בשני הצדדים ולאמת את שם המארח המיועד, אישור TLS וגרסת האפליקציה מלקוחות בלתי תלויים.
יש להגדיר חזרה לאחור לאחר תחילת הכתיבות
לפני שהמערכת החדשה מקבלת שינויים, החזרת תעבורה עשויה להיות פשוטה יחסית. לאחר מכן, היפוך DNS בלבד יכול לאבד עבודה או ליצור שתי היסטוריות מתנגשות. יש להגדיר כיצד רשומות והעלאות חדשות שנוצרו יישמרו או יותאמו. אם האפליקציה לא יכולה למזג אותן בבטחה, תקופת תחזוקה מבוקרת עשויה להיות עדיפה על חזרה מאולתרת להעתק הישן.
יש לקבוע את התנאים שמחייבים השהיית המעבר, ולהשאיר את בעל ההחלטה זמין. יש לשמר יומנים וראיות שימושיות לפי כללי השימור של הפרויקט. אין למחוק את המכונה הישנה או את עותק השחזור העצמאי שלה רק מפני שעמוד הבית נטען פעם אחת. תקופת השימור צריכה לכסות את צורכי האימות והחזרה לאחור המוסכמים.
יש לסגור את המעבר עם בדיקות תפעוליות
לאחר המעבר, יש לאמת גיבויים, התראות, חידוש אישורים, עבודה מתוזמנת ושחזור גישה. יש לאשר שהמארח המנוטר הוא היעד החדש ושאין אינטגרציות בדיקה שנותרו בייצור. יש לסקור שגיאות אפליקציה וזמני תגובה גלויים למשתמש תחת תעבורה רגילה. יש לעדכן את המלאי ואת המדריך כך שהמנהל הבא לא יצטרך להסיק מה השתנה.
המשפחות הייעודיות של SwissOctet מציעות תצורות פיזיות שונות, אך עבודת מעבר וסיוע מנוהל חייבים להיות מאושרים עבור השירות הנבחר. יש להשתמש בקטלוג כדי לבחור משאבים מתאימים, ואז לבנות מעבר נבדק סביב נתוני האפליקציה שלך. מעבר הושלם כאשר השירות ותהליך השחזור שלו עובדים ביעד, לא רק כאשר הקבצים הועברו.
רשימת הבדיקה המעשית שלך.
- יש למפות נתונים, משימות, סודות ואינטגרציות.
- יש לאמת את היעד שנמסר לפני תזמון.
- יש לתרגל עם אינטגרציות חיצוניות בטוחות.
- יש להגדיר עקביות בין מסד הנתונים להעלאות.
- יש לתכנן מעבר ניתוב ומניעת משימות כפולות.
- יש לציין חזרה לאחור עבור כתיבות חדשות.
- יש לאמת גיבויים וניטור לאחר המעבר.
הפרטים שחשובים.
האם אני יכול לבצע מעבר על ידי העתקת תיקיית האפליקציה?+
רק אם זה לוכד את כל מה שהשירות צריך ושומר על עקביות. מסדי נתונים, העלאות, משימות, סודות ותצורה דורשים בדרך כלל התייחסות נפרדת.
האם הורדת ה-TTL של DNS הופכת את המעבר למיידי?+
לא. תשובות שנשמרו קודם במטמון יכולות להישאר עד תום משך החיים הקודם שלהן, ולקוחות עשויים להתעדכן בזמנים שונים.
האם חזרה לאחור היא רק הפניית DNS לשרת הישן?+
לא לאחר שהשרת החדש מקבל כתיבות. יש להתחשב ברשומות ובקבצים האלה לפני החזרת התעבורה.
לך למקור.
הפניות אלה תומכות במושגים הטכניים במדריך זה. עקוב אחר התיעוד העדכני לפני שינוי מערכת ייצור.
- PostgreSQL: גיבוי ושחזור www.postgresql.org
- PostgreSQL: עקביות ושחזור של SQL Dump www.postgresql.org
- Apache: תיעוד מארחים וירטואליים httpd.apache.org
- Cloudflare DNS: Time to Live developers.cloudflare.com
הדרכה עריכתית מאת SwissOctet. הדוגמאות להמחשה. יש לאמת בנפרד מפרטי שירות, אפשרויות זמינות ותנאים חוזיים.