הגדרת DNS Failover לזמינות גבוהה

DNS Failover: למה צומת אחד מפיל את כל השירות

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

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

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

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

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

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

מה נותנת העברת תעבורה מנוהלת

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

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

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

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

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

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

אפשרויות DNS Failover: השוואת מצבי עבודה

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

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

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

סדר היישום: מביקורת ועד מסירה לתמיכה

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

1. ביקורת אזור. עורכים מלאי של רשומות: אילו מצביעות על צמתי ייצור, אילו משמשות דואר ושירותים, היכן האזור מואצל ומי רשאי לשנות אותו. בתוצר — מפת תלויות ורשימת רשומות שאסור לגעת בהן באוטומציה.
2. תרשים העברה. קובעים כיצד מתפזרת התעבורה בין האתרים, לפי איזה סימן נבחר הצומת הראשי וכמה מהר הרשומות מפסיקות להצביע על זה שנפל. בנפרד מתעדים את התנהגות הסשנים ומה קורה ללקוחות ברגע החלפת הכתובת.
3. הגדרת בדיקות זמינות. מגדירים מה בדיוק נבדק — תגובת השירות או תגובה יישומית, כמה אישורים נדרשים עד להפעלה ועד לחזרה, כדי לא לבצע העברה בגלל תקלה קצרה ולא „לרעוד” בין האתרים.
4. תקלת תרגול. מכבים את הצומת הראשי ובודקים את הזמן בפועל עד ההתאוששות, שיעור הבקשות שאבדו ותקינות עבודת הגיבוי תחת עומס. פער מול החישוב — סיבה לחזור לספים.
5. תיעוד. תרשים, מטריצת אחראים, סדר העברה ידנית וחזרה לאחור, נקודות שבהן האוטומציה נעצרת ונדרש אדם.
6. מסירה לתמיכה. משמרת תורנים מקבלת התראות, הוראות לתקלות אופייניות ותקנון לבדיקה תקופתית: פעם ברבעון חוזרים על תקלת תרגול, אחרת ההגדרה מתרחקת בשקט מהמציאות.

תצורות, תרשיםם ותקנונים בתוצר

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

• תצורות אזורים: קובצי אזור עם סט מלא של רשומות NS, SOA ושירות, ערכי TTL לפי סוגי רשומות, תצוגות split-horizon לרזולברים חיצוניים ופנימיים.
• בדיקות זמינות: כתובות ופורטים של בדיקות, מרווחי סקר, סף הפעלה, סדר עדיפויות ומשקלי רשומות, כללים לחזרה אוטומטית לצומת הראשי לאחר ההתאוששות.
• תרשים טופולוגיה: היכן ממוקמים הצמתים הראשיים והגיבוי, כיצד מתואמים ביניהם האזורים, אילו נתיבי רשת וכתובות מעורבים, מה קורה בעת כשל של אתר שלם.
• מדיניות גישה: תפקידים והרשאות לשינוי רשומות, הפרדת קווי סביבה, מפתחות חתימה להעברות אזורים, מגבלות וזמן חיים של אסימוני ניהול, יומן של כל השינויים.
• תקנון תורנות: אילו אירועים יוצרים התראה, מי ובאיזה פרק זמן מתייצב, סדר הסלמה, נקודות קבלת החלטה על העברה ידנית.
• הוראות לתורן: תרחישים שלב אחר שלב לירידת ביצועי רזולווינג, העברת תעבורה ידנית, בדיקת התוצאה וחזרה למצב הקודם.
• ניטור: סט מדדים לפי זמן תגובה ושיעור פתרונות מוצלחים, בדיקות סינתטיות מנקודות חיצוניות, פאנל מצב עם חלוקה לפי שירותים.

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

איך זה עובד בפועל: מדדים לפני ואחרי

לפני: העברה ידנית וגיבוי קר

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

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

אחרי: אוטומציה וגיבוי חם

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

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

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

במהלך רבעון הזמינות עלתה מ-99.5% ל-99.97%, זמן ההעברה הממוצע ירד מ-3–7 דקות ל-45–70 שניות, ושיעור התקלות שהגיעו למשתמש ירד מ-0.4% ל-0.03%. אין יותר הקמות ידניות בלילה: התורן רק מאשר שהאוטומציה פעלה כמתוכנן, והפעלות שגויות מנותחות לפי יומן ההעברות.

מה לעשות אם קו הגיבוי כבר פרוס

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

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

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

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

ספקות טכניים נפוצים לפני התחלה

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

עד כמה תכופות הפעלות שגויות של בדיקות?

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

האם אפשר להעביר רק חלק מהשירותים ומה עם הדואר?

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

איך מתבצעת החזרה לקו הראשי?

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

נדון בתבנית כשל העמידות שלכם

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

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

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