Anycast לעומת Unicast: מה עדיף לבחור בכל מקרה

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

בעיקרו של דבר, אותו מסלול מפורסם ממספר מרכזי נתונים ברחבי העולם. כך, לקוחות יישלחו ל"טוב ביותר" ול"קרוב" על סמך מסלולי BGP, מרכז הנתונים. למה Anycast? למה להשתמש ב-Anycast במקום ב-Unicast?

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

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

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

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

Anycast ו-Unicast: הבדלים

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

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

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

היתרונות של Anycast

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

מהירות

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

יציבות מוגברת וסובלנות תקלות

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

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

איזון עומסים

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

צמצם את ההשפעה של התקפות DoS 

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

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

מדרגיות אופקית גבוהה

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

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

רק בדרך זו ניתן לשרת טרה-ביטים של תעבורה ומספר גדול מאוד של משתמשים כאשר לשרת יש רק כמה יציאות של 10 או 25 Gbps. 100 מארחים עם כתובת IP אחת יאפשרו לעבד נפחי תעבורה בטרביט.

ניהול תצורה קל

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

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

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

רחוק ממקור טהור ליופי

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

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

Anycast משמש בעיקר עבור שירותים מבוססי UDP כגון DNS. בקשות משתמשים מנותבות למרכז הנתונים "הטוב ביותר" וה"קרוב ביותר" בהתבסס על מסלולי BGP.

דוגמה: תחנת עבודה של לקוח DNS עם כתובת IP של Anycast DNS של 123.10.10.10 מבצעת רזולוציית DNS לשרת הקרוב ביותר מבין שלושה שרתי שמות DNS הפרוסים באמצעות אותה כתובת IP של Anycast. אם נתב R1 או שרת A נכשלים, מנות לקוח DNS יועברו אוטומטית לשרת ה-DNS הקרוב הקרוב ביותר דרך נתבים R2 ו-R3. בנוסף, המסלול לשרת A שלנו יוסר מטבלאות הניתוב, וימנע שימוש נוסף בשרת השמות הזה.

תרחישי פריסה

ישנן שתי סכמות כלליות המשמשות כדי לקבוע לאיזה שרת משתמש מתחבר:

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

CDN מבוסס על Anycast

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

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

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

יישומים המשתמשים בפרוטוקולים כגון HTTP/TCP מסתמכים על יצירת החיבור. אם נבחר צומת Anycast חדש (לדוגמה, עקב כשל בשרת), ייתכן שהשירות יופסק. זו הסיבה ש-Anycast הומלץ בעבר לשירותים ללא חיבור כגון UDP ו-DNS. עם זאת, Anycast עובד היטב גם עבור פרוטוקולים מוכווני חיבור; לדוגמה, TCP עובד היטב במצב Anycast.

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

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

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

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

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

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

אפשר לבנות תשתית היברידית: לפעמים נוח להשאיר את ה-back office ברשת הארגונית, ולהוציא את חלק הממשק במיקור חוץ לספק.

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

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

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

הסיבה היא שבמקרה של Unycast, לכל LinkedIn PoP יש כתובת IP ייחודית. לאחר מכן משתמשים מוקצים ל-PoP על סמך מיקומם הגיאוגרפי באמצעות DNS. הבעיה היא שבשימוש ב-DNS, כ-30% מהמשתמשים בארצות הברית הופנו ל-PoP לא אופטימלי. עם ההטמעה ההדרגתית של Anycast, הקצאת PoP לא אופטימלית ירדה מ-31% ל-10%.

תוצאות מבחן הפיילוט מוצגות בגרף, כאשר ציר ה-Y הוא האחוז של הקצאת PoP האופטימלית. כאשר Anycast התגבר, מדינות רבות בארה"ב ראו שיפור באחוז התנועה לקראת ה-PoP האופטימלי.

ניטור רשת Anycast

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

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

דוגמה: כותרות תגובת HTTP המציינות את מיקומו של שרת ה-CDN.

לדוגמה, CloudFlare משתמש בכותרת CF-Ray משלה בהודעות HTTP Response, הכוללת אינדיקציה של מרכז הנתונים שאליו הוגשה הבקשה. במקרה של Zendesk, כותרת ה-CF-Ray עבור אזור סיאטל היא CF-RAY: 2a21675e65fd2a3d-SEA, ועבור אמסטרדם הוא CF-RAY: 2a216896b93a0c71-AMS. אתה יכול גם להשתמש בכותרות HTTP-X מתגובת HTTP כדי לקבוע היכן התוכן ממוקם.

שיטות פנייה אחרות

ישנן שיטות התייחסות אחרות לניתוב בקשות משתמשים לנקודת קצה ספציפית ברשת:

Unicast

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

שידור לקבוצה

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

משדר

Datagram משולח יחיד מועבר לכל נקודות הקצה המשויכות לכתובת השידור. הרשת משכפלת אוטומטית נתונים גרמות כדי שתוכל להגיע לכל הנמענים בשידור (בדרך כלל באותה רשת משנה).

Geocast

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

נתב גיאוגרפי מחשב את שטח השירות שלו ומעריך אותו. Georouters, החלפת אזורי שירות, בניית טבלאות ניתוב. למערכת הגיאראוטר יש מבנה היררכי.

Unicast, Multicast ושידור.

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

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

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

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

איך בונים CDN?

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

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

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

כמו ליצור CDN באמצעות DNS? הקמת CDN באמצעות הפתרון של Anycast יכול להיות פרויקט די יקר, אבל יש אפשרויות זולות יותר. לדוגמה, אתה יכול להשתמש ב-GeoDNS ובשרתים רגילים עם כתובות IP ייחודיות. באמצעות שירותי GeoDNS, אתה יכול ליצור CDN עם ​​יכולות מיקום גיאוגרפי, שבו ההחלטות מתקבלות על סמך המיקום האמיתי של המבקר, ולא על המיקום של פותר ה-DNS. אתה יכול להגדיר את אזור ה-DNS שלך כך שיציג כתובות IP של שרת אמריקאי למבקרים בארה"ב, אך מבקרים אירופאים יראו את כתובת ה-IP האירופית.

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

GeoDNS קובע את כתובת ה-IP של הלקוח ששלח את בקשת ה-DNS, או את כתובת ה-IP של שרת ה-DNS הרקורסי של הספק, המשמש בעת עיבוד בקשת הלקוח. המדינה/אזור נקבעים על ידי מסד הנתונים IP ו-GeoIP של הלקוח. לאחר מכן הלקוח מקבל את כתובת ה-IP של שרת ה-CDN הקרוב ביותר. אתה יכול לקרוא עוד על הגדרת GeoDNS כאן.

Anycast או GeoDNS?

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

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

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

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

При переходе на домен браузер обращается к ближайшему серверу DNS, который, в зависимости от домена, выдает IP-адрес для загрузки сайта. Предположим, интернет-магазин пользуется популярностью в CША и в Европе, а DNS-серверы для него есть только в Европе. Тогда пользователи из США, которые хотят воспользоваться услугами магазина, будут вынуждены отправлять запрос к ближайшему серверу, а так как он находится очень далеко, ждать ответа придется долго — загрузка сайта будет не быстрой.

כאשר שרת GeoDNS ממוקם בארה"ב, המשתמשים כבר יגשו אליו. התגובה תהיה מהירה, מה שישפיע על מהירות הטעינה של האתר.

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

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

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

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

רשתות משנה של לקוחות ב-DNS היא הרחבה של DNS (RFC7871) המגדירה כיצד שרתי DNS רקורסיביים יכולים לשלוח מידע לקוח לשרת ה-DNS, במיוחד מידע רשת ששרת GeoDNS יכול להשתמש בו כדי לקבוע בצורה מדויקת יותר את מיקומו של הלקוח.

רובם משתמשים בשרתי ה-DNS של ספק שירותי האינטרנט שלהם או בשרתי ה-DNS הקרובים אליהם מבחינה גיאוגרפית, אבל אם מישהו בארה"ב מסיבה כלשהי יחליט להשתמש בפותר DNS הממוקם באוסטרליה, סביר להניח שהוא יקבל את כתובת שרת ה-IP הקרובה ביותר לאוסטרליה.

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

סיכום: אם אתה רוצה לשלב מספר VPS לתוך CDN, אז אפשרות הפריסה הטובה ביותר היא להשתמש בחבילת שרת DNS עם הפונקציה GeoDNS + Anycast מחוץ לקופסה.

מקור: www.habr.com