DNS Failover וזמינות גבוהה

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

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

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

איך DNS Failover עובד

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

המנגנון פשוט: ספק ה-DNS שלך בודק ברציפות את השרתים שלך — דרך HTTP, TCP, או ICMP ping — כדי לוודא שהם מגיבים. כשהבדיקות נכשלות, הספק מסיר את כתובת ה-IP של השרת המת מתגובות ה-DNS, או מחליף אותה בכתובת גיבוי. כשהמקורי מתאושש, הוא מתווסף חזרה.

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

בדיקות בריאות שבאמת עובדות

ping מוכיח שניתן להגיע לשרת. הוא לא מוכיח שהאפליקציה שלך פועלת.

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

בדיקות בריאות אפקטיביות מאמתות את מה שחשוב: האפליקציה שלך, מקצה לקצה. בדיקת בריאות HTTP מבקשת נקודת קצה ייעודית — /health או /status — ומאמתת שהיא מחזירה 200 OK עם תוכן צפוי. בדיקות טובות יותר שואלות את מסד הנתונים, מאמתות קישוריות מטמון, מאשרות ש-API של צד שלישי ניתן להגעה. הן עונות על השאלה שמשתמשים באמת אכפת להם ממנה: "האם השרת הזה יטפל בבקשה שלי כראוי?"

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

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

פשרת ה-TTL

Time To Live קובע כמה זמן מפענחים שומרים את רשומות ה-DNS שלך במטמון. זהו גם הגורם המגביל את מהירות ה-failover שלך.

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

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

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

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

יתירות שרתי שמות

האפליקציה שלך יכולה לעבור failover בין שרתים — אבל מה קורה כש-DNS עצמו נופל?

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

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

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

Anycast: Failover במהירות רשת

Anycast עושה משהו שנשמע בלתי אפשרי: הוא מכריז על אותה כתובת IP ממיקומים מרובים בו-זמנית.

שאל כתובת DNS של Anycast, ופרוטוקולי הניתוב של האינטרנט — BGP, ספציפית — מנתבים אוטומטית את השאילתה שלך לצומת הקרוב ביותר. אותה כתובת IP קיימת בטוקיו, לונדון וניו יורק בו-זמנית. פרוטוקולי הניתוב לא יודעים ולא אכפת להם — הם פשוט מוצאים את הקרוב ביותר.

זה מספק failover מהיר יותר ממה ש-DNS יכול להשיג אי פעם. כשמרכז נתונים יוצא מהרשת, BGP מפסיק לנתב אליו תעבורה תוך שניות. ללא בדיקות בריאות, ללא פקיעת TTL, ללא עיכוב התפשטות. התעבורה זורמת אוטומטית למיקום הקרוב הבא.

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

בניית רשת Anycast משלך דורשת הקצאות כתובות IP, הסכמי BGP peering, ותשתית מפוזרת גלובלית. זו הסיבה שרוב הארגונים משתמשים בספקי DNS מתמחים — Cloudflare, Google, Route 53 — שכבר בנו זאת.

מגבלות DNS Failover

DNS failover הוא כלי בעל ערך. הוא גם מוגבל. הבנת המגבלות עוזרת לך לבנות מערכות שבאמת שורדות כשלים.

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

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

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

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

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

שאלות נפוצות על DNS Failover

עד כמה מהר DNS Failover יכול לנתב מחדש תעבורה?

עדכון ה-DNS עצמו קורה תוך שניות. אבל לקוחות לא רואים אותו עד שהרשומות שנשמרו במטמון פוגות. עם TTL של 60 שניות ובדיקות בריאות כל 10 שניות, רוב התעבורה מנותבת מחדש תוך 1–2 דקות. לקוחות עם שמירה אגרסיבית יותר במטמון עשויים לקחת יותר זמן. failover ברמת האפליקציה מהיר יותר — מילישניות, לא דקות.

האם כדאי להשתמש ב-TTL הנמוך ביותר האפשרי לצורך failover מהיר יותר?

נמוך יותר לא תמיד טוב יותר. TTL של 5 שניות אומר נפח שאילתות גבוה בהרבה שפוגע בשרתי השמות שלך, זמן אחזור מוגבר מבדיקות תכופות, ובפועל לא הרבה יותר מהירות failover מאשר 60 שניות. רוב מערכות הייצור משתמשות ב-60–300 שניות כאיזון סביר.

האם DNS Failover יכול להחליף מאזן עומסים?

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

מה קורה אם ספק ה-DNS שלי עצמו יורד?

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

מדוע חלק מהמשתמשים עדיין מגיעים לשרתים שנכשלו לאחר DNS Failover?

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