מה זה Anycast?

כשאתה מקליד 8.8.8.8 בהגדרות ה-DNS שלך, אתה לא מתחבר לשרת בודד. אתה מגיע לאחד ממאות שרתים המפוזרים בשישה יבשות, וכולם חולקים את אותה כתובת IP בדיוק.

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

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

מה עושה את Anycast לשונה

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

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

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

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

ארבע דרכים לנתב תעבורה

לאינטרנט יש ארבע שיטות ניתוב שונות מהותית:

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

Broadcast שולח תעבורה לכל מכשיר ברשת מקומית, בין אם הם רוצים זאת ובין אם לא. ARP ו-DHCP משתמשים ב-broadcast. הוא מציף רשתות בתעבורה שרוב המכשירים מתעלמים ממנה. IPv6 ביטל אותו לחלוטין.

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

Anycast שולח תעבורה לחבר הקרוב ביותר בקבוצה. שרתים מרובים מכריזים על אותה כתובת IP. מערכת הניתוב בוחרת את הקרוב ביותר אוטומטית.

כיצד Anycast עובד

Anycast מסתמך לחלוטין על BGP — פרוטוקול ה-Border Gateway שמחזיק את האינטרנט יחד.

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

כשאתה שולח בקשה ל-8.8.8.8, כל נתב לאורך הנתיב שואל את אותה שאלה: מהו המסלול הטוב ביותר לכתובת זו? המדד העיקרי הוא אורך נתיב AS — כמה מערכות אוטונומיות (רשתות נפרדות) התעבורה חייבת לעבור. נתיבים קצרים יותר מנצחים.

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

"הקרוב ביותר" לא אומר מה שאתה חושב

כאן האינטואיציה נכשלת לחלוטין.

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

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

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

השרת הקרוב ביותר טופולוגית מנצח. תמיד. גיאוגרפיה אינה רלוונטית.

איפה Anycast מפעיל את האינטרנט

שרתי שורש DNS פועלים לחלוטין על anycast. 13 שרתי השורש (A עד M) פועלים על פני יותר מ-1,950 מופעים ב-1,500+ אתרים ברחבי העולם¹. כשאתה מבצע שאילתה לשרת שורש, אתה מגיע לאחד מהמיקומים המפוזרים האלה — לעולם לא לאותה מכונה פיזית פעמיים ברצף.

ממירי DNS ציבוריים גם הם תלויים ב-anycast. ה-8.8.8.8 של Google פועל ממרכזי נתונים ברחבי העולם ומטפל בכ-30% מכל תעבורת ה-DNS². ה-1.1.1.1 של Cloudflare פועל על פני 330 ערים ברחבי העולם³.

רשתות הפצת תוכן משתמשות ב-anycast לכיוון תעבורה אל שרתי הקצה. כתובת IP anycast בודדת מייצגת אלפי מיקומי קצה, ומכוונת אוטומטית משתמשים למטמונים קרובים. Cloudflare, Akamai, Amazon CloudFront ו-Fastly בנויים כולם על כך.

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

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

מדוע Anycast חשוב

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

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

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

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

המגבלות

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

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

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

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

אין טווח כתובות מיוחד

בניגוד ל-multicast (224.0.0.0/4) או כתובות פרטיות (192.168.0.0/16), ל-anycast אין טווח IP שמור. כל כתובת הניתנת לניתוב ציבורי יכולה להיות anycast.

ההבדל הוא בתצורת הניתוב בלבד. הכרז על 8.8.8.8 ממיקום אחד: unicast. הכרז עליה מ-50 מיקומים: anycast. כתובת ה-IP לא משתנה. התנהגות הניתוב משתנה על פי כמה מקומות מכריזים עליה.

חבילה שנשלחת ל-8.8.8.8 נראית זהה בין אם היא מגיעה לשרת אחד ובין אם לאחד ממאות. Anycast שקוף לחלוטין בשכבת ה-IP — הוא קיים רק בתשתית הניתוב.

פילוסופיית העיצוב

Anycast חושף משהו על האופן שבו האינטרנט נבנה.

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

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

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

Anycast פותר את שלושתם במנגנון אחד: סמוך על הרשת שתמצא פתרון.

שאלות נפוצות על Anycast

כיצד anycast שונה מאיזון עומסים מבוסס DNS?

איזון עומסים מבוסס DNS מחזיר כתובות IP שונות למשתמשים שונים על פי מיקומם. Anycast משתמש בכתובת IP בודדת הנותבת לשרתים שונים על פי טופולוגיית הרשת. איזון עומסים DNS דורש המתנה לפקיעת TTL למעבר לגיבוי (לעתים קרובות דקות); anycast עובר למסלול גיבוי תוך שניות, דרך משיכת מסלול BGP.

האם אני יכול להשתמש ב-anycast לשירותים שלי?

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

מדוע לא כל אתרי האינטרנט משתמשים ב-anycast?

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

כיצד אני יכול לדעת אם אני משתמש בשירות anycast?

בדרך כלל לא ניתן לדעת מצד הלקוח — כתובת ה-IP נראית זהה ל-unicast. הרצת traceroute ממיקומים שונים עשויה לחשוף נתיבים שונים לאותה IP. שירותים כמו 8.8.8.8 או 1.1.1.1 ידועים כ-anycast, אבל הפרוטוקול עצמו שקוף למשתמשי קצה — כך הוא תוכנן.

מקורות