מיגרציה לענן בלי השבתה: צ׳קליסט טכני מלא

איך מבצעים מיגרציה לענן בלי השבתה? מקימים את השרת החדש במקביל לישן ומעתיקים אליו את כל הנתונים מראש. יומיים לפני המעבר מורידים את ה-TTL של רשומות ה-DNS לכמה דקות, ובודקים את השרת החדש דרך קובץ hosts בלי לחשוף אותו לגולשים. בחלון המעבר מקפיאים לזמן קצר כתיבה לשרת הישן, מריצים סנכרון אחרון של קבצים ומסד נתונים, ורק אז מעדכנים את ה-DNS. השרת הישן נשאר זמין כמה ימים כתכנית חזרה לאחור. כך ההשבתה, אם יש בכלל, נמדדת בדקות.

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

העיקרון: שתי סביבות פעילות במקביל

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

שבועיים לפני: מיפוי והכנה

• רשימת שירותים: אתרים, מסדי נתונים, שירותי דואר, משימות מתוזמנות (cron או Task Scheduler), תורים ותהליכי רקע.
• כתובות IP קשיחות: חפשו בקוד ובקבצי ההגדרות כתובות IP של השרת הישן. כל כתובת כזו תישבר אחרי המעבר.
• רשימות היתר אצל צד שלישי: חברת סליקה, ספק SMS, ממשקי API של בנקים או ספקים שמאשרים גישה רק מכתובת IP מסוימת. צריך לעדכן אותם מראש עם כתובת השרת החדש, כי חלק מהגופים מעדכנים רק בתוך כמה ימי עסקים.
• תעודות SSL: ודאו שאפשר להנפיק או להתקין את התעודה בשרת החדש לפני המעבר.
• גרסאות תוכנה: גרסת PHP, מסד הנתונים, Node או .NET בשרת החדש צריכות להתאים לקיים, או שצריך לבדוק את המערכת על הגרסה החדשה.
• גיבוי מלא ועדכני של השרת הישן, שנבדק בשחזור ולא רק נוצר.
• הגדרת "הצלחה": רשימת בדיקות קבלה שנריץ לפני שנכריז שהמעבר הושלם.

DNS ו-TTL: המפתח למעבר קצר

ה-TTL (Time To Live) קובע כמה זמן שרתי DNS ברחבי האינטרנט שומרים במטמון את הכתובת של הדומיין. אם ה-TTL הוא 24 שעות, חלק מהגולשים עלולים להמשיך להגיע לשרת הישן עד יממה אחרי שעדכנתם את הרשומה.

מתי	פעולה
לפחות TTL אחד לפני המעבר (בדרך כלל 24–48 שעות)	מורידים את ה-TTL של רשומות A/AAAA ו-CNAME הרלוונטיות ל-300 שניות
בחלון המעבר	מעדכנים את הרשומות לכתובת השרת החדש
24–48 שעות אחרי מעבר מוצלח	מחזירים את ה-TTL לערך רגיל, למשל שעה

שלושה דגשים:

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

סנכרון נתונים בשלבים

קבצים

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

מסדי נתונים

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

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

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

דואר

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

בדיקות לפני שמחליפים את ה-DNS

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

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

יום המעבר: סדר פעולות

1. בוחרים חלון שקט, בדרך כלל בלילה או בסוף שבוע, ומודיעים לגורמים הרלוונטיים.
2. מוודאים שה-TTL הנמוך כבר בתוקף.
3. מכניסים את המערכת במצב תחזוקה, או חוסמים כתיבה בשרת הישן.
4. מריצים סנכרון אחרון של קבצים ומסד נתונים.
5. מריצים שוב את בדיקות הקבלה המרכזיות דרך קובץ hosts.
6. מעדכנים את רשומות ה-DNS.
7. מפנים את השרת הישן לשרת החדש, או משאירים בו עמוד תחזוקה, כדי שגולשים עם DNS ישן לא יכתבו אליו.
8. מסירים את מצב התחזוקה ועוקבים אחרי לוגים ושגיאות.

דגשים להעברת שרת Windows עסקי

שרת Windows שהעובדים מתחברים אליו בשולחן עבודה מרוחק (RDP), או שמריץ תוכנת הנהלת חשבונות, ERP או תיקיות משותפות, דורש כמה בדיקות נוספות:

• פרופילים של משתמשים: הגדרות, מדפסות ומסמכים שנשמרו בפרופיל המקומי צריכים לעבור, או שהמשתמשים יגלו שולחן עבודה ריק.
• כונני רשת ממופים: אם הם מוגדרים לפי שם השרת או כתובת ה-IP הישנה, צריך לעדכן אותם, ידנית או דרך מדיניות קבוצתית.
• רישוי: רישיונות גישה מרחוק (RDS CAL) ורישיונות של תוכנות שקשורים לשם המחשב או לחומרה. ודאו מול היצרן איך מעבירים אותם.
• מדפסות וסורקים: ציוד משרדי שמחובר לרשת המקומית לא יהיה זמין לשרת בענן בלי חיבור VPN או פתרון הדפסה מרחוק.
• קיצורי דרך אצל העובדים: הכינו קובץ חיבור RDP מעודכן והפיצו אותו לפני יום המעבר, עם הוראות קצרות.

מי עושה מה ביום המעבר

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

תכנית חזרה לאחור (Rollback)

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

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

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

72 השעות הראשונות

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

טעויות נפוצות

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

שאלות נפוצות

אפשר באמת להעביר שרת לענן בלי שום השבתה?

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

כמה זמן לפני המעבר צריך להוריד את ה-TTL?

לפחות פרק זמן אחד של ה-TTL הנוכחי. אם הוא 24 שעות, מורידים אותו לפחות יממה מראש, ועדיף יומיים.

מה עושים עם מיילים שמגיעים לשרת הישן בזמן המעבר?

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

צריך לעדכן את חברת הסליקה?

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

מתי מותר לכבות את השרת הישן?

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

מתכננים להעביר שרת? בחרו שרת VPS בישראל, שקלו שרת VPS מנוהל שבו הצוות שלנו מלווה את ההקמה, או דברו איתנו לתכנון המעבר.