כיצד להשתמש באמזון מסלול 53?

הבן כי ניתן להשתמש בכביש 53 בכדי לעשות דבר כמו איזון עומסים.

• למשל, אם ברצונך לאזן תנועה נכנסת בין שלושה שרתים, תוכל להגדיר רשומת כביש 53 A עם כתובות ה- IP של כל השרתים. ניתן גם להגדיר מספר רשומות של כביש 53 A עם משקלים שונים, תוך שימוש במדיניות ניתוב משוקללת (נדון בהמשך עמוד זה).
• לעומת זאת, באפשרותך להשתמש במאזנת עומסים כדי לקבל תעבורה נכנסת ואז להשתמש במאזנת עומסים זו כדי להעביר את התעבורה לשרתים השונים.

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

• מכיוון שהתנועה למעשה לא עוברת דרך נקודה מרכזית כלשהי, ניתן להשתמש בכביש 53 להפצת תנועה מחדש בין אזורים מבלי להוסיף זמן הלוך ושוב לחביון. עם מאזן עומסים, הזמן הלוך ושוב בין איזון העומס לשרת שמעבד לבסוף את הבקשה מתווסף לחביון של משתמש הקצה. למשל, אם אנו רוצים לוודא שאנשים באירופה מקבלים שירות על ידי שרתים באירופה ואילו אנשים במזרח אסיה מקבלים שירות על ידי שרתים במזרח אסיה (לזמן אחזור מינימלי) המנתבים תנועה דרך מאזן עומסים מביס את המטרה בגלל הסיבוב הנוסף. -זמן טיול. עם זאת, אנו יכולים להשתמש ברשומות כביש 53 למטרה זו מבלי להוסיף לחביון, מכיוון שרשומות כביש 53 נפתרות באופן מקומי מבלי לבצע נסיעה לשרת מרכזי. יתר על כן, עקב מטמון (עד TTL) של החיפושים,אפילו החלטה מקומית זו צריכה להיעשות רק פעם בדקה.
• כביש 53 הוא גם חסון יותר בהשבתה, מכיוון שיש לו מספר רב של מיקומי קצה העונים לבקשות, והוא תוכנן על בסיס העיקרון של עבודה מתמדת כדי למנוע כישלון מדורג.
• לניתוב מבוסס כביש 53 יש יתרון ביחס למאזני עומסים אלסטיים של אמזון (ELBs) בכך שהוא יכול להתמקד במהירות רבה לעומסים גדולים, ואילו ELB לא יכולים להתמודד עם שינויים מהירים מאוד ובעומסים גדולים מספיק. שים לב כי ELB מספיק טובה לרוב מקרי השימוש, אך, למשל, חברת הכניסה לוגלי גילתה כי כביש 53 שימש את מקרה השימוש שלה טוב יותר. שים לב כי Loggly הוא יוצא דופן ביחס לרוב שירותי האינטרנט או ה- API שיש עומס יציב או צפוי יותר. מחלקת הייחוס שלה היא "ניהול חירום" המשלב חיזוי עם שינויים מהירים מאוד בעומס בזמנים מסוימים.

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

• לא ניתן להשתמש בכביש 53 כדי לראות את הציון הכולל של התנועה.
• כביש 53 אינו טוב להפצת תעבורה באופן שווה בין שרתים. הסיבה לכך היא שלמרות שהיא מאפשרת אסטרטגיית בדיקת IP של רובין, זה רק לחיפושי IP ו- _ לא_ לבקשות בפועל. לכן, אם חלוקת מקורות הבקשה אינה אחידה לחלוטין, הרי שהתפלגות התעבורה יכולה להיות גם לא אחידה. זה חשוב במיוחד אם אתה מציע שירות API למספר קטן של לקוחות עם עומס גבוה לכל לקוח.
• כביש 53 אינו יכול להפיץ תנועה באופן שווה כפי שמאזן עומסים יכול להיות. לדוגמא, מאזן העומסים האלסטי של אמזון משתמש באלגוריתם של לפחות מינימום: הוא מעביר בקשה לשרת עם מספר הבקשות הנמוך ביותר. זה עוזר להפחית את עומס התנועה בשרתים איטיים או שאינם מגיבים יותר. זה לא אפשרי בכביש 53 מכיוון שהתנועה אפילו לא זורמת דרכה, ואין לה מודעות לזמני התגובה של שרתים בודדים.
• לא ניתן להוסיף או להסיר שרתים מכביש 53 במהירות האפשרית עם איזון עומסים. כביש 53 גם לא יכול להיות משולב ישירות בניתוח האוטומטי שמציעה AWS, אם כי ניתן לכתוב סקריפטים שיוצרים שרתים חדשים ומוסיפים להם רשומות באמצעות ממשק ה- API של כביש 53 בהתבסס על עומס התעבורה המנוסה כיום, כפי שלחברת רישום לוגלי יש בוצע.

עם כל האזהרות הללו, חשוב לציין כי מסלול 53 ואיזון עומסים הם משלים, ולא מתחרים.

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

הבן כי נתיב 53 ורשתות מסירת תוכן (CDN) חולקות את התכונה שהן מופצות באופן מאסיבי, עם מיקומי קצה ברחבי העולם.

• למעשה, כביש 53 ושירותי אמזון CloudFront (שירות דמוי CDN של אמזון) חולקים מיקומי יתרון.

הבן כי מסלול 53 משרת כתובות IP, בעוד ש- CDN מגיש תוכן.

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

הבן שיש דרך מעניינת להשתמש ב- cdns כנקודות מרכזיות של זרימת התנועה, כלומר להאיץ את לחיצת היד המשולשת המשמשת ליצירת החיבור הראשוני. כביש 53 אינו מציע זאת.

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

• לכל אזור שמתארח בציבור יש רשומת NS אחת (שרת שמות) המציינת את ארבעת שרתי שמות האמזונס שישמשו לפתרון הדומיין ותתי הדומיינים שלו. קבוצה זו של ארבעה שרתי שמות נקראת קבוצת משלחת. כדי להעביר את רשומות ה- DNS לכביש 53 של אמזון, עליך לעדכן את רשימת ארבעת שרתי השמות אצל הרשם (שם רשמת את הדומיין) למערך זה של ארבעה שרתי שמות. עד לרשימה זו עשויות להימשך 24-48 שעות עדכנית ברחבי העולם.
• לכל אזור שמתארח בציבור יש גם רשומת SOA (Start of Authority) המספקת מידע סמכותי על הדומיין, כולל שרת השמות הראשי, דוא"ל מנהל הדומיין, המספר הסידורי של הדומיין וטיימרים הקשורים לרענון האזור.
• ערכת המשלחת בדרך כלל שונה באזורים שונים שמתארחים בציבור. עם זאת, ניתן להשתמש ב- API 53 של כביש 53 כדי להשתמש באותה קבוצת משלחת עבור אזורים ציבוריים שונים. זה עוזר להקל על העברת אירוח למספר רב של אתרים מכיוון שרשמים רבים מאפשרים למשתמשים לציין סט ברירת מחדל של שרת שמות לשימוש בכל התחומים שלהם.

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

• לכל מערך רשומות יש קבוצת כתובות שתת-הדומיין עשוי לפתור אליהן. כתובות אלה יכולות להיות כתובות IP (שעשויות להיות מופעי EC2 או לא) או שמות DNS (כגון עבור EC2 ELB, דלי S3 שמוגדרים כאתר סטטי או הפצה של CloudFront). שים לב שכאשר אנו משתמשים בשמות DNS, שם ה- DNS בתורו עשוי להיפתר לכתובת IP אחת או יותר. לדוגמא, EC2 ELB בדרך כלל יפתור למספר כתובות IP, כאשר מספר כתובות ה- IP תלוי במספר אזורי הזמינות שהוא פועל בהם, כמו גם בעומס התעבורה שהוא מטפל בו.
• כל מערך רשומות משויך לדומיין או לתת-דומיין של הדומיין המשויך לאזור המתארח, וממלא תפקיד בפתרון דומיין זה. באופן כללי, ניתן (ומכריע) לקיים מספר ערכות רשומות (שלכל אחת מהן יכולות להיות מספר רשומות) עבור תת-דומיין יחיד.
• לכל מערך רשומות יש סוג רשומה. סוגי הרשומות הם קבוצת משנה של סוגי רשומות ה- DNS. סוגי הרשומות החשובים ביותר למקרי שימוש רגיל הם רשומות כתובת (רשומות A) ורשומות Canonical Name (רשומות CNAME). ה- CNAME הגיוני כשאתה פשוט משכתב תת-דומיין אחד למשנהו. שיא ה- A הרבה יותר תכליתי.
• בעת שימוש ברשומה המצביעה ישירות על כתובת ה- IP של מופע EC2, וודא שכתובת ה- IP היא IP אלסטי כך שהיא תשרוד את סיום המופע וניתן לחבר אותה למופע חדש.
• בעת שימוש ברשומת A או CNAME עבור מאזן עומסים אלסטי, הפצה של CloudFront, דלי S3 שהוגדר כאתר סטטי או רשומה של כביש 53, ניתן להגדיר אותו ככינוי. שיא כינוי פשוט remaps תחום המשנה את שם ה- DNS זה יש כינוי, ולכן משנה לאחרון נאספים באופן אוטומטי על ידי לשעבר. זה מאפשר לרשומות A לקבל חלק מהיתרונות של רשומות CNAME ובכל זאת מאפשרת רשומות מרובות לכל תת-דומיין. זה גם מאפשר אינטגרציה מעמיקה יותר עם המשאבים הבסיסיים, כולל הערכה ישירה של בריאות היעד מבלי להגדיר בדיקות בריאות נפרדות. הרעיון של שיא הכינוי הוצג על ידי DNSimple (לא מזוהה עם כביש 53 של אמזון). היישום של אמזון שונה במקצת מזה של DNSimple. אמזון מציעה מדריך לשימוש בכינויי כינוי לעומת ערכות שיא משאבים שאינן כינוי.
• במקרה של קבוצות שיא מרובות עבור תת-דומיין מסוים, והתמונה המלאה כיצד חיפושי DNS עבור תת-דומיין זה יפתרו תלויה בכל מערכי הרשומות ובאינטראקציה שלהם.

הבן את מושגי הבריאות במסלול 53. סוגים מסוימים של מערכי שיא תומכים בבדיקות בריאות ובהערכה של בריאות היעד.

• לכל סוג רשומה (כינוי או לא, וללא קשר לסוג הרשומה) עם מדיניות שאינה "פשוטה" (סוגי הרשומות נדונים בחלק הבא) תוכלו לשייך בדיקת תקינות. זה יכול להעביר נקודת קצה ספציפית (עם יציאה שתוכל לציין) באמצעות פרוטוקול HTTP (פרוטוקולים אחרים אינם נתמכים) ולחפש מחרוזת חיפוש ספציפית בתגובה. ניתן להגדיר את מרווח הבקשה ל -10 שניות או 30 שניות. מגבלת הזמן הקצוב לתגובה, אורך קטע התגובה הראשוני שתותאם למחרוזת החיפוש, ושבר בדיקות הבריאות שצריכות לעבור כדי שנקודת הקצה תיחשב לבריאה, נשלטות על ידי אמזון ולא ניתנות להגדרה על ידי המשתמש.
• האפשרות "הערך בריאות יעד" זמינה עבור רשומות כינוי (רשומות CNAME או A) ללא קשר למדיניות. מכיוון שאופציה זו מוצעת רק למשאבים ספציפיים של אמזון, היא יכולה ליהנות משילוב עמוק עם המשאבים הבסיסיים. לדוגמא, במקרה המיוחד של רשומות Alias (רשומות CNAME או A) המצביעות על ELBs של אמזון EC2, הערכת בריאות היעד עוברת אם ורק אם ל- ELB יש לפחות מופע אחד שרשום ומשמש. זהו אינטגרציה עמוקה מאחורי הקלעים בין שני שירותי AWS (כביש 53 ו- ELB).

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

הבן את מדיניות הניתוב "המשוקללת". מדיניות ניתוב נפוצה נוספת היא מדיניות ניתוב "משוקללת". כאן, כל מערך שיאים המשויך לתת-תחום מקבל משקל. במסגרת ערכת השיא, כל כתובות ה- IP הנפרדות נפתרות באמצעות אסטרטגיית סבב רובין. על פני מערכי השיא, ההסתברות לשימוש בערכת שיאים נתונה היא היחס בין משקל השיא שנקבע לסכום המשקולות של כל מערכי השיא לתת-תחום. לדוגמא, אם יש קבוצות שיא של משקולות 3, 2, 2 ו- 1 בהתאמה עבור תת-תחום, הן נבחרות בהסתברות של 0,38, 0,25, 0,25 ו- 0,13 בהתאמה.

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

הבן את מדיניות הניתוב "חביון". ניתוב מבוסס חביון (LBR) הוא אחד ממדיניות הניתוב המתוחכמת יותר. כל רשומת חביון מציינת אזור שירותי האינטרנט של אמזון.

• הנתב המבוסס על חביון, כאשר הוא מתבקש לפתור את תת-הדומיין, בוחן את טבלת ההשהיה המעודכנת מעת לעת בין האזורים הבאים: מיקום הקצה הקרוב ביותר לכתובת ה- IP שעושה את החיפוש, ואזור שירותי האינטרנט של אמזון שצוין בערכת הרשומות..
• שים לב כי אין זה הגיוני כי הרשומות בערכת הרשומות ממוקמות באזור AWS שצוין לניתוב מבוסס חביון. למעשה, ייתכן שהרשומות שלך אינן מופיעות בתשתית AWS כלל! אם הם נמצאים בתשתית AWS, זה הגיוני להשתמש באזור AWS בו הם נמצאים. אחרת, זה הגיוני להשתמש באזור AWS הקרוב ביותר, כדי להציע את ה- proxy הטוב ביותר לאיחורים לרשומות אלה.
• בדומה למקרה של רשומות משוקללות, ערכות רשומות מבוססות חביון הגיוניות רק כאשר יש יותר מאחת מהן. במקרה זה, זמן ההשהיה עבור כל מערך רשומות מחושב כמוסבר לעיל (על ידי בדיקת טבלה של זמן אחזור בין מיקום הקצה הקרוב ביותר למבקש לבין אזור ה- AWS שצוין בערכת הרשומות). לאחר מכן מוחזר השיא שנקבע עם השהיה הנמוכה ביותר.
• שים לב, במיוחד, כי אומדן חביון זה עשוי להיות שונה מאוד מהשיהוי בפועל של שאילתות, משתי סיבות: הוא משתמש בהשהיה ממיקומי קצה לאזור AWS ולא מהלקוח בפועל לשרת בפועל, ושנית, זה מתעלם מזמן העיבוד בשרתים עצמם, שיכול להשתנות בין אזורים.
• בפרט, בניגוד לאיזון העומסים הזעיר ביותר בשימוש ELBs של אמזון, המפיץ מחדש את התעבורה בהתאמה על בסיס הבדלי חביון, כביש 53 אינו לוקח בחשבון מידע אודות חביון השאילתות בפועל. אנו יכולים לדמיין באופן אידיאלי שאם אזור אחד איטי יותר מאחר, האזור השני יתפוס נתח גדול יותר של תנועה ממקומות גיאוגרפיים אי שם באמצע השניים. ניתוב מבוסס חביון אין לא לעשות זאת.
• ידוע כי אלגוריתם הניתוב מבוסס חביון כושל, מכיוון שלעתים הוא מנתב תנועה למיקום שגוי. לכן, אם חביון באמת חשוב לך ויש לך קבוצה קטנה של לקוחות המשתמשים בכבדות בממשק ה- API שלך, עדיף לתת להם תת-דומיינים אשר פותרים ישירות לאזורים מסוימים במקום להשתמש ב- LBR בתקווה שהם ינותבו נכון.

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

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

• אם אתה משייך בדיקות בריאות למערכי הרשומות של כביש 53, אז מערכת שיאים מסוימת מוציאה מהעמלה לאחר שנכשלה בשלושה בדיקות בריאות עוקבות (יתכן שניתן להגדיר את מספר הכשלים). באופן דומה, אם אתה מעריך את בריאות היעד של ה- ELB, מערכת שיא מוציאה מהעמלה ברגע שהיעד מתגלה כלא בריא. מערכי השיא חוזרים לפעול ברגע שבדיקת הבריאות או היעד הבריאותי יחזרו לקדמותם. הזמן המרבי שההשפעה תהיה גלובלית הוא 150 שניות: 3 בדיקות כושלות של 30 שניות, בתוספת TTL של 60 שניות (שימו לב שניתן להגדיר את ה- TTL ואם תגדירו אותו לארוך יותר ייקח יותר זמן עד שהשינוי יתפשט).
• למדיניות ניתוב משוקללת, המשמעות היא שהמשקולות במערכות השיא שעדיין לא בריאות הן גדלות באופן יחסי.
• עבור מדיניות ניתוב מבוססת חביון, המשמעות היא שאם מערך רשומות יורד לחלוטין, כל התעבורה שהייתה מנותבת לשם מנותבת במקום זאת לאזור השהיה הבא הנמוך ביותר עבור אותו חלק מסוים של התנועה. לכן, העומס על האזורים האחרים לא יגדל באותו שיעור, אלא הוא יגדל בהתבסס על קרבתם לתעבורה ששימשה את האזור שהגיע למטה. זה יכול להוביל לכישלון מדורג. לדוגמה, נניח שיש לך שלושה אזורים: us-west-1, us-east-1 ו- eu-west-1, עם שיא אחד שנקבע לכל אחד, והגדרת יכולת לטפל בעומסי תנועה אופייניים לכל אזור. עכשיו, נניח ש- east-1 -1 יורד. במקרה זה, כמעט כל התנועה לנו-מזרח -1 תעבור לנו-מערב -1, האזור הקרוב ביותר לרוב התנועה שתעבור לנו-מזרח -1. זה יכול להיות גידול משמעותי בתעבורה עבור us-west-1, והעומס המוגבר עלול לגרום לקריסת האזור. כעת, כל התנועה העולמית פוגעת ב- eu-west-1, מה שעלול לגרום לקריסת אזור זה. התוצאה היא שכישלון פסיבי יכול למעשה לגרום לקריסה עולמית ללא תכנון מוקפד. הבעיה חריפה יותר מאשר במדיניות ניתוב משוקללת בגלל כמה הרבה תעבורה מנותבת לאזור אחד.
• אפשר גם להגדיר ערכות תקליטים המפורשות ככשל. ערכות שיא אלה משמשות רק אם כל מערכי התקליטים האחרים יוצאים מהעמלה. אנו יכולים להשתמש בהם כדי להגיש גיבויים סטטיים.

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

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

הבן כי מסלול 53 הוא חלק מרכזי בתצורה מרובת אזורים.

• השקיעו לפחות כמה שעות בכדי לוודא שמדיניות כביש 53 שלכם נקבעה בצורה סבירה.
• בדקו את השימוש במדיניות התעבורה וזרימת התנועה המאפשרים לכם לאחסן תצורות מורכבות. ב בטווח הארוך, לחיצה סביב במסוף כדי לשנות מדיניות היא לא רעיון טוב עבור מרכיב עיקרי לזמינות שלך.
• בדוק שילוב עדכונים ל- API 53 של כביש בסקריפטים לפריסה שלך (כגון סקריפטים של Ansible או Chef).

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

שקול גישות כיבוד יצירתיות המופעלות על ידי מסלול 53.

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

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

• מי יכול לחפש מידע רישומי סמכותי עבור תחומים.
• ניתן להשתמש ב- nslookup כדי לקבל מידע על שרת השמות.
• dig (הפקודה היעילה ביותר עבור איתור באגים בכביש 53) יכול למצוא את כתובות ה- IP המשויכות לתת-דומיין נתון, ותוכל לוודא שהתוצאות שהוחזרו תואמות למדיניות הניתוב שלך. זה גם מדפיס את ה- TTL שנותר. כאשר אתה מוציא את הפקודה הראשונה, זה אמור להיות ה- TTL המלא שלך. הפעלות לאחר מכן בתוך ה- TTL צריכות להראות את ה- TTL שנותר. לדוגמה, אם ה- TTL שלך הוא 60 שניות, הריצה של חפירה לאחר 15 שניות אמורה להציג TTL של 45 שניות. אם שם DNS A כולל רשומות כינוי מבוססות חביון המצביעים על שם DNS B ושם DNS C, אתה יכול לחפור את כל שלושת השמות ואז לראות אם כתובות ה- IP שאליו A פותר תואמות את כתובות ה- IP ש- B ו- C פותרות אליהן. ניתן גם לציין אפשרות + עקיבה לחפירה להדפסת המעקב.
• traceroute שימושי גם כדי לקבל מידע ברור יותר על אופן התרחשות הרזולוציה.
• ניתן להשתמש ב- ping לשאילתת כתובת ה- DNS ולקבלת אומדנים של זמן הלוך ושוב.
• באמצעות curl או wget ניתן להגיש בקשת HTTP ולקבל תגובה.
• באפשרותך להפעיל פקודות מעטפת אלה ממכונתך שלך או על ידי כניסה לשרתים מרוחקים במקומות שונים.