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

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

עמוד זה מתאר כיצד להשתמש בשירות Route 53 של אמזון, מערכת שמות מתחם ניתנת להרחבה וזמינה ביותר, מערכת רישום תחומים ושירות בדיקת בריאות. המוקד של מאמר זה הוא השימוש ברישומי כתובת (A) וברשומות שם קנוני (CNAME) בכביש 53, המשמעות של רשומות Alias, כמו גם התפקיד שממלאות מדיניות הניתוב ובדיקות הבריאות.

שים לב שבמסלול 53 יש מספר מתחרים וניתן להשתמש בהם בארכיטקטורה שאינה מתארחת ב- aws.

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

חלק 1 מתוך 6: הבנת מסלול 53

1
הבן כיצד מסלול 53 מסייע ללקוחות לפתור בקשות DNS עבור הדומיין או תת-הדומיין שלך.
- כביש 53 יכול לשמש כ- DNS סמכותי עבור התחומים והתת-דומיינים שלך. המשמעות היא שכל מי שרוצה לחפש את התחום שלך חייב לקבל אותו מכביש 53 באופן ישיר או עקיף.
- כתובת ה- IP אותה מחזיר כביש 53 עבור דומיין ללקוח מחושבת על סמך כתובת ה- IP של הלקוח ומערכי הרשומות והמדיניות של כביש 53 שהוגדרו על ידך.
- מדיניות הניתוב המשמשת את כביש 53 יכולה לקחת בחשבון את תקינות נקודות הקצה בדרכים שונות (בדיקות תקינות של TCP, בדיקות תקינות של מצב קצה HTTP עם התאמת מחרוזות).
- כביש 53 עוקב אחר "עיקרון של עבודה מתמדת": כמות העבודה שבוצע על ידי כביש 53 אינה תלויה בבריאות נקודות הקצה הנבדקות. זאת בכדי להימנע מבעיית "כישלונות מדורגים" שהופעלו על ידי פעולות כביש 53. זה לא מונע את האפשרות שבדיקות בריאות של כביש 53 יובילו בעקיפין לתקלות מדורגות בגלל הפניית תנועה; עם זאת, כביש 53 עצמו נותר חסון.
- לערכות שיא של כביש 53 יש Time To Live (TTL) משלהן שניתן להגדיר ל 60 שניות ומעלה. כל לקוח או פותר DNS ביניים אמור לכבד את ה- TTL הזה: אם הוא לא רענן את הרזולוציה של התחום או תת-הדומיין למשך ה- TTL או יותר, עליו לרענן את המידע. ככל ש TTL קצר יותר, כך תדירות החיפושים בכביש 53 גדולה יותר ועלות השימוש בשירות גבוהה יותר. בפועל, עלויות אלה זניחות עד שמגיעים למיליוני כניסות, ובדרך כלל היתרונות של TTL קצרים יותר מציפים את החסרונות בקנה מידה זה בגלל המהירות בה תוכלו לבצע ולתקן שינויים באופן התנועה העולמית.
2
הבן כי מסלול 53 משתמש במידע על חביון וזמינות ממקומות שונים בעולם. לפיכך, הוא יכול להשתמש בכתובת IP דינמית ומגיבה.
- בכביש 53 יש מיקומי קצה ברחבי העולם. זה קובע זמינות ואיחור מכל אחד ממיקומי הקצה הללו לכל אחד מאזורי שירותי האינטרנט של אמזון.
- בנוסף, כביש 53 מבצע כל בדיקת בריאות באופן עצמאי מכל אחד ממיקומי הקצה. באפשרותך להציג, לכל בדיקת בריאות, את ההיסטוריה של פעילות בדיקת הבריאות האחרונה, כולל הן ה- IP של בודק הבריאות, ה- IP שביקורת הבריאות החליטה עליו והאם בדיקת הבריאות הצליחה.
- כאשר לקוח מבצע חיפוש של דומיין או תת-דומיין בכביש 53, הוא משלב שלוש פיסות מידע: (א) כתובת ה- IP של הלקוח, (ב) המידע העדכני ביותר לגבי זמינות, חביון ובריאות, ו- (ג) להגדיר ערכות רשומות ומדיניות ניתוב להגיב. מכיוון שתדירות בדיקת הבריאות היא 10-30 שניות (תלוי בהגדרה) וה- TTL המינימלי הוא 60 שניות, הזמן המינימלי להפצת שינויים מבוססי בדיקת בריאות הוא 90-150 שניות, והזמן המינימלי להפצת שינויים אחרים הוא 60 שניות.
3
מעריך שתנועה לא זורמת דרך כביש 53, ולכן היא לא עוקבת אחר התנועה בפועל.
- מסלול 53 משמש רק את הלקוחות לחיפוש כתובות IP. הבקשות בפועל אינן מנותבות דרך כביש 53.
- אפילו לחיפוש כתובות IP, לא כל הלקוחות נוגעים ישירות בכביש 53. יש אחסון במטמון ברמה של דפדפנים בודדים: דפדפן יאחסן במטמון את כתובות ה- IP באופן מקומי למשך ה- TTL. יכול להיות שיש שמירה גם ברמת ביניים. למשל, אם שני משתמשים שונים המשתמשים באותו ספק אינטרנט באותו אזור מחפשים את אותה כתובת בהפרש זמן זה מזה שהוא פחות מ- TTL, המשתמש השני עשוי לקבל את הכתובת במטמון של פותר ה- DNS של ספק האינטרנט מהראשון. את בקשת המשתמש, במקום ללכת עד לכביש 53, שרת ה- DNS המוסמך.
- לכן ספירת הבקשות לכביש 53 אינה מספקת אומדן טוב של התנועה בפועל לכתובות ה- IP שנבדקו.
4
שים לב שבמסלול 53 יש מספר מתחרים וניתן להשתמש בהם בארכיטקטורה שאינה מתארחת ב- aws. לעומת זאת, המתחרים שלה יכולים להתארח בארכיטקטורה המתארחת ב- AWS.
- המתחרות הגדולות ביותר בכביש 53 כוללות את UltraDNS, Dyn, Cotendo, easyDNS ו- DNS Made Easy. לכביש 53 זמינות דומה יחסית למתחרים, אך חביון התפשטות מעט מהיר יותר ועלות מעט נמוכה יותר. עם זאת, אמזון.קום עצמה לא משתמשת בכביש 53, מה שעשוי להיות סיבה להיות מעט סקפטיים לגבי האמינות שלה לפריסה גבוהה במיוחד.
- דרך 53 כמו גם מתחרותיה יכולים לשמש לשרתים המתארחים בתשתית אמזון (כלומר EC2) וכן לשרתים המתארחים במקומות אחרים.
- בכביש 53 יש קרסים טובים יותר ל- EC2 (למשל, זה יכול להצביע על ELBs ולהעריך את בריאותם במהירות) ולכן הגיוני במיוחד להשתמש כאשר מתמודדים עם EC2. יש לו גם גישה פרוגרמטית טובה ובדיקות בריאות.

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

חלק 2 מתוך 6: הבנת קווי הדמיון וההבדלים העיקריים בין מסלול 53 לאיזון עומסים

1
הבן כי ניתן להשתמש בכביש 53 בכדי לעשות דבר כמו איזון עומסים.
- למשל, אם ברצונך לאזן תנועה נכנסת בין שלושה שרתים, תוכל להגדיר רשומת כביש 53 A עם כתובות ה- IP של כל השרתים. ניתן גם להגדיר מספר רשומות של כביש 53 A עם משקלים שונים, תוך שימוש במדיניות ניתוב משוקללת (נדון בהמשך עמוד זה).
- לעומת זאת, באפשרותך להשתמש במאזנת עומסים כדי לקבל תעבורה נכנסת ואז להשתמש במאזנת עומסים זו כדי להעביר את התעבורה לשרתים השונים.
2
הבן שכיוון שמסלול 53 אינו כולל נקודת זרימת תנועה מרכזית כלשהי, ישנם דברים שהוא יכול לעשות שמאזני עומסים אינם יכולים לעשות.
- מכיוון שהתנועה למעשה לא עוברת דרך נקודה מרכזית כלשהי, ניתן להשתמש בכביש 53 להפצת תנועה מחדש בין אזורים מבלי להוסיף זמן הלוך ושוב לחביון. עם מאזן עומסים, הזמן הלוך ושוב בין איזון העומס לשרת שמעבד לבסוף את הבקשה מתווסף לחביון של משתמש הקצה. למשל, אם אנו רוצים לוודא שאנשים באירופה מקבלים שירות על ידי שרתים באירופה ואילו אנשים במזרח אסיה מקבלים שירות על ידי שרתים במזרח אסיה (לזמן אחזור מינימלי) המנתבים תנועה דרך מאזן עומסים מביס את המטרה בגלל הסיבוב הנוסף. -זמן טיול. עם זאת, אנו יכולים להשתמש ברשומות כביש 53 למטרה זו מבלי להוסיף לחביון, מכיוון שרשומות כביש 53 נפתרות באופן מקומי מבלי לבצע נסיעה לשרת מרכזי. יתר על כן, עקב מטמון (עד TTL) של החיפושים,אפילו החלטה מקומית זו צריכה להיעשות רק פעם בדקה.
- כביש 53 הוא גם חסון יותר בהשבתה, מכיוון שיש לו מספר רב של מיקומי קצה העונים לבקשות, והוא תוכנן על בסיס העיקרון של עבודה מתמדת כדי למנוע כישלון מדורג.
- לניתוב מבוסס כביש 53 יש יתרון ביחס למאזני עומסים אלסטיים של אמזון (ELBs) בכך שהוא יכול להתמקד במהירות רבה לעומסים גדולים, ואילו ELB לא יכולים להתמודד עם שינויים מהירים מאוד ובעומסים גדולים מספיק. שים לב כי ELB מספיק טובה לרוב מקרי השימוש, אך, למשל, חברת הכניסה לוגלי גילתה כי כביש 53 שימש את מקרה השימוש שלה טוב יותר. שים לב כי Loggly הוא יוצא דופן ביחס לרוב שירותי האינטרנט או ה- API שיש עומס יציב או צפוי יותר. מחלקת הייחוס שלה היא "ניהול חירום" המשלב חיזוי עם שינויים מהירים מאוד בעומס בזמנים מסוימים.
3
הבן שכיוון שמסלול 53 אינו כולל נקודה מרכזית של זרימת תנועה, הוא אינו יכול לעשות חלק מהדברים שמאזני עומסים יכולים לעשות.
- לא ניתן להשתמש בכביש 53 כדי לראות את הציון הכולל של התנועה.
- כביש 53 אינו טוב להפצת תעבורה באופן שווה בין שרתים. הסיבה לכך היא שלמרות שהיא מאפשרת אסטרטגיית בדיקת IP של רובין, זה רק לחיפושי IP ו- _ לא_ לבקשות בפועל. לכן, אם חלוקת מקורות הבקשה אינה אחידה לחלוטין, הרי שהתפלגות התעבורה יכולה להיות גם לא אחידה. זה חשוב במיוחד אם אתה מציע שירות API למספר קטן של לקוחות עם עומס גבוה לכל לקוח.
- כביש 53 אינו יכול להפיץ תנועה באופן שווה כפי שמאזן עומסים יכול להיות. לדוגמא, מאזן העומסים האלסטי של אמזון משתמש באלגוריתם של לפחות מינימום: הוא מעביר בקשה לשרת עם מספר הבקשות הנמוך ביותר. זה עוזר להפחית את עומס התנועה בשרתים איטיים או שאינם מגיבים יותר. זה לא אפשרי בכביש 53 מכיוון שהתנועה אפילו לא זורמת דרכה, ואין לה מודעות לזמני התגובה של שרתים בודדים.
- לא ניתן להוסיף או להסיר שרתים מכביש 53 במהירות האפשרית עם איזון עומסים. כביש 53 גם לא יכול להיות משולב ישירות בניתוח האוטומטי שמציעה AWS, אם כי ניתן לכתוב סקריפטים שיוצרים שרתים חדשים ומוסיפים להם רשומות באמצעות ממשק ה- API של כביש 53 בהתבסס על עומס התעבורה המנוסה כיום, כפי שלחברת רישום לוגלי יש בוצע.
4
עם כל האזהרות הללו, חשוב לציין כי מסלול 53 ואיזון עומסים הם משלים, ולא מתחרים.
- איזון עומסים הוא מתאים ביותר להפצת תנועה באופן שוויוני, ועל שמירה על זמינות גבוהה, תוך אזור.
- כביש 53 הוא המתאים ביותר להבטחת זמינות בין אזורים, למזער חביון וטיפול בכמויות יתירות וכישלון מעבר לאזור.

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

חלק 3 מתוך 6: הבנת הדמיון והשוני בין מסלול 53 ל- CDN (כגון ענן ענן)

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

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

חלק 4 מתוך 6: הבנת מסלול המפתח 53 מושגים: אזור מתארח, בדיקת בריאות וערכת שיאים

1
להבין את הרעיון של אזור מתארח בציבור. אזור מתארח בציבור הוא מיכל לכל ערכות הרשומות המשויכות לדומיין אינטרנט ולתת-הדומיינים שלו.
- לכל אזור שמתארח בציבור יש רשומת NS אחת (שרת שמות) המציינת את ארבעת שרתי שמות האמזונס שישמשו לפתרון הדומיין ותתי הדומיינים שלו. קבוצה זו של ארבעה שרתי שמות נקראת קבוצת משלחת. כדי להעביר את רשומות ה- DNS לכביש 53 של אמזון, עליך לעדכן את רשימת ארבעת שרתי השמות אצל הרשם (שם רשמת את הדומיין) למערך זה של ארבעה שרתי שמות. עד לרשימה זו עשויות להימשך 24-48 שעות עדכנית ברחבי העולם.
- לכל אזור שמתארח בציבור יש גם רשומת SOA (Start of Authority) המספקת מידע סמכותי על הדומיין, כולל שרת השמות הראשי, דוא"ל מנהל הדומיין, המספר הסידורי של הדומיין וטיימרים הקשורים לרענון האזור.
- ערכת המשלחת בדרך כלל שונה באזורים שונים שמתארחים בציבור. עם זאת, ניתן להשתמש ב- API 53 של כביש 53 כדי להשתמש באותה קבוצת משלחת עבור אזורים ציבוריים שונים. זה עוזר להקל על העברת אירוח למספר רב של אתרים מכיוון שרשמים רבים מאפשרים למשתמשים לציין סט ברירת מחדל של שרת שמות לשימוש בכל התחומים שלהם.
2
להבין את המושג ערכות שיא. הפריטים הבודדים בכל אזור מתארח נקראים ערכות שיא. אלה תואמים רשומות 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 עבור תת-דומיין זה יפתרו תלויה בכל מערכי הרשומות ובאינטראקציה שלהם.
3
הבן את מושגי הבריאות במסלול 53. סוגים מסוימים של מערכי שיא תומכים בבדיקות בריאות ובהערכה של בריאות היעד.
- לכל סוג רשומה (כינוי או לא, וללא קשר לסוג הרשומה) עם מדיניות שאינה "פשוטה" (סוגי הרשומות נדונים בחלק הבא) תוכלו לשייך בדיקת תקינות. זה יכול להעביר נקודת קצה ספציפית (עם יציאה שתוכל לציין) באמצעות פרוטוקול HTTP (פרוטוקולים אחרים אינם נתמכים) ולחפש מחרוזת חיפוש ספציפית בתגובה. ניתן להגדיר את מרווח הבקשה ל -10 שניות או 30 שניות. מגבלת הזמן הקצוב לתגובה, אורך קטע התגובה הראשוני שתותאם למחרוזת החיפוש, ושבר בדיקות הבריאות שצריכות לעבור כדי שנקודת הקצה תיחשב לבריאה, נשלטות על ידי אמזון ולא ניתנות להגדרה על ידי המשתמש.
- האפשרות "הערך בריאות יעד" זמינה עבור רשומות כינוי (רשומות CNAME או A) ללא קשר למדיניות. מכיוון שאופציה זו מוצעת רק למשאבים ספציפיים של אמזון, היא יכולה ליהנות משילוב עמוק עם המשאבים הבסיסיים. לדוגמא, במקרה המיוחד של רשומות Alias (רשומות CNAME או A) המצביעות על ELBs של אמזון EC2, הערכת בריאות היעד עוברת אם ורק אם ל- ELB יש לפחות מופע אחד שרשום ומשמש. זהו אינטגרציה עמוקה מאחורי הקלעים בין שני שירותי AWS (כביש 53 ו- ELB).

חלק 2 מתוך 6: הבנת הדמיון העיקרי וההבדלים בין מסלול 53 לבין איזון עומסים.

חלק 5 מתוך 6: הבנת מדיניות ניתוב ובחירת מדיניות מתאימה

1

הבן את מדיניות הניתוב ה"פשוטה ". מדיניות הניתוב הפשוטה ביותר היא מדיניות ניתוב "פשוטה". זה מתאים למקרים שבהם יש רק שיא אחד המשויך לתת-הדומיין. מדיניות ניתוב פשוטה יכולה לכלול מספר כתובות IP או DNS, ותפתור לכל אחת מהן חלק שווה מהזמן. באופן ספציפי, הוא פועל לפי אסטרטגיית רובין. מדיניות ניתוב פשוטה משתלבת היטב עם רשומות CNAME. כמו תמיד, השתמש ברשומת כינוי אם אתה מצביע לכתובת DNS של EC2 כגון מאזן עומסים אלסטי, והעריך את מצב היעד.
2
הבן את מדיניות הניתוב "המשוקללת". מדיניות ניתוב נפוצה נוספת היא מדיניות ניתוב "משוקללת". כאן, כל מערך שיאים המשויך לתת-תחום מקבל משקל. במסגרת ערכת השיא, כל כתובות ה- IP הנפרדות נפתרות באמצעות אסטרטגיית סבב רובין. על פני מערכי השיא, ההסתברות לשימוש בערכת שיאים נתונה היא היחס בין משקל השיא שנקבע לסכום המשקולות של כל מערכי השיא לתת-תחום. לדוגמא, אם יש קבוצות שיא של משקולות 3, 2, 2 ו- 1 בהתאמה עבור תת-תחום, הן נבחרות בהסתברות של 0,38, 0,25, 0,25 ו- 0,13 בהתאמה.
- מדיניות ניתוב משוקללת הגיונית רק במקרה של מערכי שיא מרובים, כולם משתמשים במדיניות ניתוב משוקללת.
- בדרך כלל, עבור מדיניות ניתוב משוקללת, אנו מציינים רק כתובת IP אחת או רשומת DNS A לכל ערכת רשומות, ולכן אנו יוצרים מספר ערכות רשומות כמו מספר כתובות ה- IP או רשומות ה- DNS A.
- שים לב שהמשקל המספרי המשויך לרשומה שנקבעה במדיניות ניתוב משוקללת אינו נותן תמונה מלאה על ההסתברות לשימוש בערכת שיא זו: עלינו לדעת את המכנה (סכום המשקולות בכל מערכי השיא). בפרט, אם נוסיף מערך רשומות חדש, ההסתברות לפתור לכל אחת מערכות הרשומות האחרות יורדת באותה פרופורציה. באופן דומה, אם המשקל באחת מערכות השיא משתנה, הדבר משפיע על ההסתברות לכל ערכות השיא האחרות.
3
הבן את מדיניות הניתוב "חביון". ניתוב מבוסס חביון (LBR) הוא אחד ממדיניות הניתוב המתוחכמת יותר. כל רשומת חביון מציינת אזור שירותי האינטרנט של אמזון.
- הנתב המבוסס על חביון, כאשר הוא מתבקש לפתור את תת-הדומיין, בוחן את טבלת ההשהיה המעודכנת מעת לעת בין האזורים הבאים: מיקום הקצה הקרוב ביותר לכתובת ה- IP שעושה את החיפוש, ואזור שירותי האינטרנט של אמזון שצוין בערכת הרשומות..
- שים לב כי אין זה הגיוני כי הרשומות בערכת הרשומות ממוקמות באזור AWS שצוין לניתוב מבוסס חביון. למעשה, ייתכן שהרשומות שלך אינן מופיעות בתשתית AWS כלל! אם הם נמצאים בתשתית AWS, זה הגיוני להשתמש באזור AWS בו הם נמצאים. אחרת, זה הגיוני להשתמש באזור AWS הקרוב ביותר, כדי להציע את ה- proxy הטוב ביותר לאיחורים לרשומות אלה.
- בדומה למקרה של רשומות משוקללות, ערכות רשומות מבוססות חביון הגיוניות רק כאשר יש יותר מאחת מהן. במקרה זה, זמן ההשהיה עבור כל מערך רשומות מחושב כמוסבר לעיל (על ידי בדיקת טבלה של זמן אחזור בין מיקום הקצה הקרוב ביותר למבקש לבין אזור ה- AWS שצוין בערכת הרשומות). לאחר מכן מוחזר השיא שנקבע עם השהיה הנמוכה ביותר.
- שים לב, במיוחד, כי אומדן חביון זה עשוי להיות שונה מאוד מהשיהוי בפועל של שאילתות, משתי סיבות: הוא משתמש בהשהיה ממיקומי קצה לאזור AWS ולא מהלקוח בפועל לשרת בפועל, ושנית, זה מתעלם מזמן העיבוד בשרתים עצמם, שיכול להשתנות בין אזורים.
- בפרט, בניגוד לאיזון העומסים הזעיר ביותר בשימוש ELBs של אמזון, המפיץ מחדש את התעבורה בהתאמה על בסיס הבדלי חביון, כביש 53 אינו לוקח בחשבון מידע אודות חביון השאילתות בפועל. אנו יכולים לדמיין באופן אידיאלי שאם אזור אחד איטי יותר מאחר, האזור השני יתפוס נתח גדול יותר של תנועה ממקומות גיאוגרפיים אי שם באמצע השניים. ניתוב מבוסס חביון אין לא לעשות זאת.
- ידוע כי אלגוריתם הניתוב מבוסס חביון כושל, מכיוון שלעתים הוא מנתב תנועה למיקום שגוי. לכן, אם חביון באמת חשוב לך ויש לך קבוצה קטנה של לקוחות המשתמשים בכבדות בממשק ה- API שלך, עדיף לתת להם תת-דומיינים אשר פותרים ישירות לאזורים מסוימים במקום להשתמש ב- LBR בתקווה שהם ינותבו נכון.
4

הבן את מדיניות הניתוב "מיקום גיאוגרפי". זה דומה לניתוב מבוסס חביון, אך מאפשר מפרט מפורש אילו מיקומים גיאוגרפיים צריכים להיות ממופים לאילו ערכות שיא.
5
הבן את המדיניות בנושא ניתוב כשל. כביש 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, מה שעלול לגרום לקריסת אזור זה. התוצאה היא שכישלון פסיבי יכול למעשה לגרום לקריסה עולמית ללא תכנון מוקפד. הבעיה חריפה יותר מאשר במדיניות ניתוב משוקללת בגלל כמה הרבה תעבורה מנותבת לאזור אחד.
- אפשר גם להגדיר ערכות תקליטים המפורשות ככשל. ערכות שיא אלה משמשות רק אם כל מערכי התקליטים האחרים יוצאים מהעמלה. אנו יכולים להשתמש בהם כדי להגיש גיבויים סטטיים.
6
תכנון תוך התחשבות בקושי לעבור. זה יכול להיות קשה להחליף מדיניות סוג רשומות, כינויים וניתוב במסוף כביש 53.
- למשל, קיימות אילוצים בערכות הרשומות עבור תת-דומיין מסוים: איננו יכולים לערבב רשומות משוקללות מבוססות חביון, ואין לנו יותר מרשומה אחת פשוטה.
- אחת הדרכים לצאת מהאתגר הזה היא להתחיל במבנה עץ של רשומות מלכתחילה, ומאפשר ליצור ענף חדש של העץ. אמזון מציעה מדריכים בנושא תצורת DNS מורכבת.
- השימוש ב- Route 53 API מעניק גמישות רבה יותר עם ביצוע שינויים מאשר שימוש במסוף מכיוון שניתן לבצע שינויים מורכבים יותר במהירות, וכך למזער את זמן ההשבתה במהלך שינויים מסובכים בין תצורות.

קרא גם: כיצד להעתיק מוסיקה מתקליטור ל- USB?

חלק 6 מתוך 6: הכנה להפיכת מסלול 53 לחלק מתשתית עם זמינות גבוהה

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

תכנון להימנע מפגיעות מכשלים ניתוב מבוססי חביון. כפי שצוין קודם לכן, אם חביון חשוב במיוחד עבור לקוח, או אם מסיבה אחרת אתה רוצה שלקוח מסוים יגיע לנקודת הקצה של ה- API שלך באזור מסוים, עדיף לתת לו תת-דומיין שעבורו הגדרת רשומות בלבד. לאזור זה, במקום להסתמך על ניתוב מבוסס חביון או מיקום מבוסס גיאוגרפי. אלה בדרך כלל לא נכשלים, אבל כאשר הם כן, אתה חסר אונים.
3
שקול גישות כיבוד יצירתיות המופעלות על ידי מסלול 53.
- היבט אחד של ניתוב מבוסס חביון שאינו מוערך לעיתים קרובות הוא שאתה יכול להשתמש בו לניתוב תנועה לאזור שאינו האזור הקרוב ביותר.
- אחת הדרכים בהן תוכלו להשתמש בכך היא כדלקמן. נניח שיש לך שני סיכויים לשאול על שרת backend. לרוב, השרת מגיב נכון בהזדמנות הראשונה. עם זאת, אם זה נכשל, זה יכול להיות בגלל בעיות ספציפיות לאזור (כמו שרתים באזור עומסים יתר על המידה, או בעיות קישוריות עם האזור). לכן אתה רוצה שהשאילתה הראשונה תהיה לאזור הקרוב ביותר מבחינה גיאוגרפית, אך השאילתה השנייה תהיה לאזור אחר שאינו הכי קרוב מבחינה גיאוגרפית אלא (בתקווה) שנייה הכי קרוב.
- אתה יכול לעשות זאת על ידי שני תת-דומיינים, אחד לבחירתך הראשון ואחד לבחירתך השנייה. רשומות כביש 53 עבור תת-הדומיין הראשון פשוט משתמשות בניתוב מבוסס חביון כפי שהוגדר כברירת מחדל (כלומר, אתה יוצר ערכת רשומות אחת עבור תת-דומיין זה ולכל אזור פעיל, ומנתבת את התנועה הקרובה ביותר לאזור זה לשרתים באותו אזור). רישומי כביש 53 עבור תת-הדומיין השני משתמשים בניתוב מבוסס חביון, אך שולחים תנועה הקרובה ביותר לאזור אחד לאזור אחר. זה מבטיח ששני הסיכויים שלך מנוצלים מול אזורים שונים.
- שים לב כי זה אינו מהווה תחליף עבור בדיקות תקינות והערכות בריאות יעד, אבל זה עושה במקרי כתובת שבה אזור עמוס במקצת אך עדיין ברובו בריא. זה גם מונע את הבעיה של כישלון מדורגים, כאשר אזור עם אחוז כישלונות גבוה בסופו של דבר עשוי לקבל תנועה נוספת עקב ניסיונות שניים.
4
הכירו את פקודות המעטפת לצורך ניפוי שגיאות טוב יותר.
- מי יכול לחפש מידע רישומי סמכותי עבור תחומים.
- ניתן להשתמש ב- 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 ולקבל תגובה.
- באפשרותך להפעיל פקודות מעטפת אלה ממכונתך שלך או על ידי כניסה לשרתים מרוחקים במקומות שונים.
5

זהה כמה מקומות מקוונים לפתרון כתובות DNS ממקומות רבים ודיווח על כתובות ה- IP. כמה דוגמאות הן whatsmydns.net ו- check-host.net.