לכל סיפור אימה על מעבר שרתים יש אותו אמצע: מישהו שינה קודם את ה-DNS ורק אחר כך התחיל להעתיק. השבתה בזמן מעבר כמעט אף פעם לא נובעת מהעתקה איטית. היא נובעת מביצוע השלבים בסדר הלא נכון.
זה הסדר שעובד, בין אם אתם עוזבים ספק אחר ובין אם אתם עוברים בין שתי תוכניות שלנו.
1. יומיים לפני: הורידו את ה-TTL
מצאו את רשומות ה-DNS שתשנו (בדרך כלל A, AAAA וכל CNAME שמצביע עליהן) והורידו את ה-TTL שלהן ל-300 שניות. אחר כך חכו לפחות כמשך ה-TTL הישן. רשומה עם TTL של יממה אומרת שחלק מהרזולברים ימשיכו להגיש את הכתובת הישנה עוד יממה אחרי השינוי, ושום דבר שתעשו בשרת לא יזרז את זה.
זה השלב שאנשים מדלגים עליו, והוא בדיוק מה שהופך החלפה של חמש דקות ליום שבו חצי מהמשתמשים רואים את השרת הישן.
2. ערכו מלאי של השרת הישן
אתם עומדים לבנות את המכונה הזאת מחדש במקום אחר, אז רשמו מה היא עושה בפועל. לא מה שאתם זוכרים. מה שהיא עושה:
ss -tlnp # what is listening, and which process
crontab -l; ls /etc/cron.d # scheduled jobs
systemctl list-timers --all # the scheduled jobs people forget
systemctl list-units --type=service --state=running
הוסיפו לרשימה: תעודות TLS ואופן החידוש שלהן, קובצי סביבה עם סודות, חוקי חומת אש, משתמשים ומפתחות ה-SSH שלהם, מסד הנתונים והגודל שלו, וכל מה שמדבר עם השרת דרך כתובת IP. הקבוצה האחרונה היא הערמומית: רשימת ההיתרים של שותף, הגדרות ה-webhook של ספק תשלומים, בדיקת ניטור.
3. הקימו את השרת החדש ליד הישן
הזמינו את השרת החדש ואל תיגעו בישן. בחרו תוכנית מרשימת ה-VPS עם דיסק באותו גודל או גדול יותר ממה שאתם משתמשים בפועל, לא ממה שמכרו לכם. אם המכונה הישנה מקבלת תעבורה נכנסת כלשהי (אתר, webhooks, API), החדשה צריכה IPv4 משלה. תוכנית NAT מקבלת חיבורים נכנסים רק בפורט ה-SSH שלה, ומה פורט מועבר אחד יכול לעשות ומה לא מסביר למה זה חשוב.
התחברו, התקינו את אותן חבילות, צרו מחדש את המשתמשים ואת חומת האש. המדריך להתחברות מכסה מפתחות וכניסה ראשונה.
4. סנכרנו את הקבצים פעמיים
הסנכרון הראשון מעתיק הכול בזמן שהשרת הישן ממשיך לעבוד. זה יכול לקחת שעות; זה בסדר.
rsync -aHAX --numeric-ids --info=progress2 /var/www/ root@203.0.113.10:/var/www/
--numeric-ids שומר על בעלות הקבצים לפי מספר, וכך נמנעת ההפתעה הקלאסית "הכול שייך למשתמש הלא נכון" כששתי המערכות יצרו משתמשים בסדר שונה. אם מעולם לא השתמשתם ב-rsync דרך SSH, איך מעבירים קבצים ל-VPS מסביר את זה צעד אחר צעד.
הסנכרון השני, ממש לפני ההחלפה, מעתיק רק את מה שהשתנה מאז הראשון. בדרך כלל זה לוקח שניות.
5. העבירו את מסד הנתונים במחשבה
קבצים זה קל. מסד נתונים שמקבל כתיבות הוא החלק היחיד שבו "בלי השבתה" דורש או פשרה קטנה או יותר עבודה.
הדרך הפשוטה: לעשות dump ושחזור פעם אחת לבדיקה, ובזמן ההחלפה לעצור כתיבות לדקה (להעביר את האפליקציה למצב קריאה בלבד או לעצור אותה), לעשות dump טרי, לשחזר אותו בשרת החדש ולהפעיל שם את האפליקציה. לרוב הפרויקטים הקטנים זו הפסקה של דקה או שתיים, שמודיעים עליה מראש.
הדרך בלי הפסקה: להגדיר רפליקציה מהמסד הישן לחדש, לתת לה להשלים פערים, ובזמן ההחלפה לקדם את החדש לראשי. יותר הכנה, וזה שווה את זה כשאפילו דקה של כתיבות שאבדו אינה מקובלת.
6. בדקו את השרת החדש לפני שמישהו אחר רואה אותו
ה-DNS עדיין מצביע על השרת הישן, אז אפשר לבדוק את החדש בשקט. שלחו בקשה לדומיין האמיתי שלכם אל הכתובת החדשה:
curl --resolve example.com:443:203.0.113.10 https://example.com/health
אם התעודה עוד לא שם, בדקו באותה דרך ב-HTTP, או הוסיפו שורה זמנית לקובץ hosts ועברו על האתר בדפדפן. בדקו התחברות, העלאות, משימות רקע ודואר יוצא. זה הרגע הזול ביותר לגלות שחסרה הרחבת PHP.
7. החליפו, והשאירו את השרת הישן פועל
בצעו את סנכרון הקבצים האחרון ואת שלב מסד הנתונים, ואז שנו את רשומות ה-DNS. עם TTL של 300 שניות רוב התעבורה עוברת תוך דקות. עקבו אחרי לוג הגישה של השרת הישן: עדיין יגיע אליו טפטוף של בקשות מרזולברים ולקוחות שמתעלמים מה-TTL. השאירו אותו פועל ללא שינוי כמה ימים. אחר כך עדכנו כל מה שמצביע על ה-IP הישן: רשימות היתרים של שותפים, כתובות webhook, ולדואר את ה-DNS ההפוך של הכתובת החדשה (בתוכניות ה-IP הייעודי שלנו אתם מגדירים אותו בעצמכם, ראו DNS הפוך) ואת רשומת ה-SPF.
מה נשבר הכי הרבה
בערך לפי הסדר שבו אנחנו רואים את זה: טיימר של systemd שאף אחד לא רשם, קובץ קונפיגורציה עם ה-IP הישן כתוב בו קשיח, קבצים ששייכים למשתמש הלא נכון, חומת אש שחוסמת את הפורט של האפליקציה עצמה, תעודה שמתחדשת בשרת הישן אבל לא בחדש, ודואר שנוחת בספאם כי לכתובת החדשה עוד אין DNS הפוך.
איפה רשימת הבדיקה הזאת לא מתאימה
מסד נתונים עמוס עם כתיבות רצופות ובלי שום סובלנות להפסקה צריך רפליקציה אמיתית וחזרה גנרלית, לא רשימת בדיקה מבלוג. שרתי Windows עוברים בכלים אחרים מ-rsync. ואם המעבר בעצם נוגע לגודל, קראו קודם את זה: כאן תוכניות גדלות במקום. מעבר לתוכנית גדולה יותר מאותו סוג רשת מוסיף vCPU, זיכרון ודיסק בהפעלה מחדש אחת, בלי שום מעבר. שרת חדש נחוץ רק כדי להקטין. אם אתם עוברים כי אינכם בטוחים שהמכונה מספיקה, מתי באמת צריך 64 GB זיכרון עשוי לחסוך לכם את הנסיעה, וVPS, אחסון משותף, שרת ייעודי או ענן יעזור אם אינכם בטוחים ש-VPS הוא בכלל הבית הנכון.
תגובות
אין עדיין תגובות. היו הראשונים.