עודכן לפני חודש
DNS round-robin הוא איזון עומסים ממש כמו שהטלת מטבע היא דרך לקבל החלטות — מבחינה טכנית זה מחלק, אבל אין שום אינטליגנציה מאחורי ההחלטה.
כיצד זה עובד
יוצרים מספר רשומות DNS מסוג A שמצביעות על אותו שם מארח לכתובות IP שונות:
כאשר resolver מבצע שאילתה עבור example.com, שרת השמות הסמכותי מחזיר את כל שלוש הכתובות ומשנה את סדרן בכל שאילתה. שאילתה ראשונה: 192.0.2.1, 192.0.2.2, 192.0.2.3. שאילתה הבאה: 192.0.2.2, 192.0.2.3, 192.0.2.1. מכיוון שרוב הלקוחות משתמשים בכתובת הראשונה ברשימה, התעבורה מתפזרת על פני שלושת השרתים.
בתיאוריה.
בעיית המטמון
מטמון DNS הורס את לוגיקת ההפצה של round-robin. כאשר resolver רקורסיבי מאחסן את רשומות ה-DNS שלכם במטמון, כל לקוח שמשתמש ב-resolver הזה מקבל את אותה רשימה מסודרת עד שה-TTL פג.
שקלו מה זה אומר בפועל. ה-resolver של Comcast משרת מיליוני משתמשים. כאשר הוא מאחסן את תגובת ה-DNS שלכם עם 192.0.2.1 בראש הרשימה, מיליוני משתמשים מתחברים לאותו שרת. בינתיים, שני השרתים האחרים שלכם יושבים ומחכים. הגדרתם שלושה שרתים וציפיתם שכל אחד יקבל 33% מהתעבורה. בפועל, שרת אחד מטפל ב-70% מהעומס — פשוט בגלל הרגע שבו ה-resolvers של ה-ISPs השונים ביצעו שאילתה לשרת השמות שלכם.
הבעיה מחמירה בכמה שכבות. Resolvers רקורסיביים מאחסנים מטמון. מערכות הפעלה מאחסנות מטמון. דפדפנים מאחסנות מטמון. חלק מהלקוחות מתעלמים לחלוטין מ-TTLs — אפליקציות Java, בפרט, יכולות לאחסן DNS במטמון ללא הגבלת זמן, בלי קשר ל-TTL שהגדרתם. הסיבוב שמתרחש בשרת השמות הסמכותי שלכם הופך לחסר משמעות. המטמון כבר קבע לאן התעבורה תגיע.
TTLs קצרים מחלקים מחדש את התעבורה לעתים קרובות יותר, אך מגדילים את נפח שאילתות ה-DNS ומוסיפים השהיה. TTLs ארוכים מפחיתים את העומס על ה-DNS אך כובלים משתמשים לאותו שרת לפרקי זמן ממושכים. אף אחת מהאפשרויות לא פותרת את הבעיה היסודית: אין לכם שליטה על האופן שבו resolvers ולקוחות מאחסנים ומסדרים מחדש את הרשומות שלכם.
אין מודעות לתקינות
ל-DNS round-robin אין שום מושג אם השרתים שלכם בכלל פעילים. אם אחד קורס, ה-DNS ממשיך לפרסם את כתובת ה-IP שלו. משתמשים שמנסים להתחבר לכתובת זו רואים תפוגות חיבור. הם מחכים. הם נכשלים. חלק מהלקוחות בסופו של דבר מנסים את הכתובת הבאה ברשימה, אך הניסיון החוזר הזה עולה 30 שניות של עיכוב.
אפשר להסיר ידנית את רשומת ה-A של השרת הכושל, אך אז מחכים שהמטמונים יפגו. עם TTL של 5 דקות, משתמשים חווים כשלים במשך 5 דקות. עם TTLs ארוכים יותר — ההפסקה ארוכה יותר. אין failover אוטומטי, אין בדיקת תקינות, אין שום אינטליגנציה.
זה הופך את DNS round-robin לבלתי מתאים לכל דבר שדורש זמינות גבוהה. כשלים לא מטופלים בצורה גרועה — הם לא מטופלים בכלל.
ההפצה אף פעם לא אחידה
גם אם מתעלמים ממטמון וכשלים, DNS round-robin מפיץ חיבורים — לא עומס. חיבור אחד עשוי להיות אפליקציית מובייל שמבצעת 1,000 קריאות API בדקה. אחר עשוי להיות מישהו שטוען דף אינטרנט אחד ומתנתק. Round-robin מתייחס לשניהם אותו דבר.
אין אפיניות סשן. אם האפליקציה שלכם דורשת שמשתמשים יישארו מחוברים לאותו שרת backend, DNS round-robin לא יעזור כאן. משתמשים עלולים לפגוש שרתים שונים בכל בקשה עוקבת, מה שישבור את מצב הסשן — אלא אם כן יישמתם אחסון סשנים מבוזר.
גיאוגרפיה נעלמת לחלוטין. משתמש בסינגפור יתחבר לשרת שלכם בווירג'יניה גם אם יש לכם שרת מצוין בטוקיו. DNS round-robin לא יודע ולא אכפת לו מאיפה מגיעים המשתמשים.
מתי זה כן עובד
למרות הכל, ל-DNS round-robin יש שימושים לגיטימיים:
שרתי שיקוף לתוכן סטטי. כל שרת מחזיר תוכן זהה. כשלים מדי פעם — מקובלים. Round-robin מספק הפצה בחינם, ללא תשתית נוספת.
סביבות פיתוח. הפצה מושלמת לא חשובה כאן. פשטות ההגדרה היא כל מה שצריך.
שירותים stateless לקריאה בלבד. כל שרת יכול לטפל בכל בקשה. אין מצב סשן. מקבלים הפצה לא אחידה, אבל גם לא משלמים כלום על היישום.
ההחלפה ברורה: מחליפים אמינות בפשטות.
חלופות מודרניות
אפליקציות ייצור שזקוקות לאיזון עומסים אמיתי משתמשות בפתרונות ייעודיים.
מאזני עומסים בשכבה 4 כגון HAProxy או NGINX מבצעים בדיקות תקינות, מוציאים שרתים כושלים מהמחזור באופן אוטומטי, ומפיצים לפי ספירות חיבורים בפועל או עומס שרת.
מאזני עומסים בשכבה 7 מוסיפים מודעות לאפליקציה — ניתוב לפי נתיבי URL, כותרות HTTP, או תוכן הבקשה. הם מסיימים SSL, מנהלים סשנים, ומקבלים החלטות ניתוב חכמות.
מאזני עומסים בענן (AWS ELB, Google Cloud Load Balancing, Azure Load Balancer) מספקים בדיקת תקינות מנוהלת, התרחבות אוטומטית, והפצה גיאוגרפית — ללא צורך לתחזק תשתית.
GeoDNS ו-Anycast מטפלים במגבלות הגיאוגרפיות על ידי ניתוב משתמשים לשרתים הקרובים אליהם. CDNs משלבים הפצה גיאוגרפית עם מטמון וניהול תעבורה.
כל הפתרונות האלה עולים יותר מ-DNS round-robin. אבל הם עובדים.
שאלות נפוצות על DNS Round-Robin
מדוע חלק מ-resolvers מסדרים מחדש תגובות DNS?
RFC 3484 תיקנן התנהגות שבה resolvers יכולים לסדר מחדש כתובות IP כדי להעדיף רשתות "קרובות יותר מבחינה מספרית". הרשימה שסיבבתם בקפידה עשויה להיות מסודרת מחדש לפני שהלקוח בכלל רואה אותה. בשילוב עם מטמון, זה אומר שההפצה שהגדרתם בשרת השמות דומה מעט מאוד לדפוסי התעבורה בפועל.
האם ניתן לשלב DNS round-robin עם בדיקת תקינות?
שירותי DNS מנוהלים מסוימים, כגון AWS Route 53 ו-NS1, מציעים round-robin עם בדיקת תקינות — ומסירים כתובות IP כושלות מהסיבוב באופן אוטומטי. זה מטפל בחולשה הגדולה ביותר, אך מוסיף עלות ומורכבות. בנקודה זו, כבר לא מדובר ב-round-robin פשוט — אלא בצורה פרימיטיבית של Global Server Load Balancing.
כיצד דפדפנים מטפלים בכשלי DNS round-robin?
ההתנהגות משתנה. דפדפנים מסוימים מנסים כתובות IP חלופיות לאחר תפוגת חיבור (בדרך כלל 30 שניות). אחרים נדבקים לכתובת IP הראשונה, בלי קשר לאם היא מגיבה. אלגוריתם "Happy Eyeballs" של Chrome מנסה מספר כתובות במקביל לצורך נפילה מהירה יותר, אך זה לא אוניברסלי. לא ניתן לסמוך על התנהגות ניסיון חוזר של לקוחות כבסיס לזמינות.
האם DNS round-robin אי פעם עדיף על מאזן עומסים?
מבחינת פשטות גרידא — כן. מאזן עומסים הוא תשתית שצריך לפרוס, להגדיר, לנטר ולתחזק. DNS round-robin הן כמה רשומות A. אם הדרישות שלכם צנועות — שירותים stateless, סובלנות לכשלים מדי פעם, ואין צורך באפיניות סשן — פשטות ה-round-robin יכולה לעלות על מגבלותיו.
מקורות
האם דף זה היה מועיל?