מדיניות ניתוב DNS ובדיקות תקינות

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

Cloud DNS תומך בכללי המדיניות הבאים של ניתוב:

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

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

לא ניתן להגדיר כללי מדיניות ניתוב DNS בתחומים הפרטיים הבאים:

  • אזורי העברה
  • תחומים של קישור DNS בין רשתות שכנות (peering)
  • תחומים מנוהלים של חיפוש הפוך
  • תחומים ב-Service Directory

כללי ניתוב של WRR

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

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

כללי מדיניות לניתוב לפי מיקום גיאוגרפי

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

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

  • ב-DNS ציבורי, משתמשים בכתובת ה-IP של המקור או בתת-הרשת של לקוח Extension Mechanism for DNS‏ (EDNS) של השאילתה.
  • ב-DNS פרטי, לא נעשה שימוש בתת-הרשת של לקוח EDNS. במקום זאת, המיקום של השאילתה הוא המיקום של המערכת ששולחת את החבילות של השאילתה:
    • בשאילתות ממכונה וירטואלית (VM) של Compute Engine עם ממשק רשת ברשת VPC, המיקום של השאילתה הוא האזור שמכיל את המכונה הווירטואלית.
    • בשאילתות שהתקבלו על ידי נקודת כניסה למדיניות שרת נכנסת, המיקום של השאילתה הוא האזור של המנהרה של Cloud VPN, הצירוף של Cloud Interconnect VLAN או מכשיר הנתב שקיבלו את החבילות של השאילתה. האזור של כתובת ה-IP של נקודת הכניסה לא רלוונטי. למידע נוסף, ראו רשת ואזור לשאילתות נכנסות.

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

מדיניות ניתוב לפי מיקום גיאוגרפי עם גדר גיאוגרפי

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

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

כללי מדיניות ניתוב של חלופות

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

במצב פעילות רגיל, Cloud DNS תמיד מחזיר את כתובות ה-IP מקבוצת active. כשכל כתובות ה-IP בקבוצה active הופכות ללא תקינות, Cloud DNS מציג את כתובות ה-IP מקבוצה backup. אם מגדירים את הקבוצה backup כמדיניות ניתוב לפי מיקום גיאוגרפי, היא פועלת כפי שמתואר בקטע מדיניות ניתוב לפי מיקום גיאוגרפי. אם מגדירים את הקבוצה backup למאזן עומסים פנימי, בדיקות התקינות של Cloud DNS בודקות את כל כתובות ה-IP הווירטואליות (VIP) לגיבוי.

Cloud DNS מאפשר לכם להעביר בהדרגה תנועה לכתובות ה-VIP לגיבוי, כדי שתוכלו לוודא שכתובות ה-VIP לגיבוי פועלות. אפשר להגדיר את אחוז התנועה שנשלחת לגיבוי כחלק מ-0 עד 1. אפשר להפעיל ידנית מעבר חירום על ידי שליחת 100% מהתנועה לכתובות ה-VIP לגיבוי. הערך הטיפוסי הוא 0.1. אפשר להחיל את בדיקות התקינות רק על מאזני עומסים פנימיים ועל נקודות קצה חיצוניות.

בדיקות תקינות

Cloud DNS תומך בבדיקות תקינות וביתירות כשל בתוך מדיניות הניתוב של מאזני העומסים הפנימיים ונקודות הקצה החיצוניות הבאים:

כשרוצים להשתמש בבדיקת תקינות עם תחום מנוהל ותוספי האבטחה של DNS‏ (DNSSEC) מופעלים, אפשר להשתמש רק בכתובת IP אחת בכל פריט מדיניות(WRR או מיקום גיאוגרפי). אי אפשר לשלב במדיניות ספציפית כתובות IP שעברו בדיקת תקינות וכתובות IP שלא עברו בדיקת תקינות.

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

בדיקות תקינות למאזני עומסים פנימיים

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

במאזני עומסים פנימיים של אפליקציות (ALB) ובמאזני עומסים פנימיים של רשתות (NLB) מסוג proxy, ‏Cloud DNS מתייחס למצב של מאזן העומסים עצמו בזמן קבלת ההחלטה לגבי הניתוב. כשמאזן העומסים מקבל שאילתה, הוא מפזר את התנועה רק לשירותי הקצה העורפי שעובדים כמו שצריך. כדי לוודא שיש קצוות עורפיים תקינים, אפשר לנהל את מחזור החיים שלהם באמצעות שירותים כמו קבוצות מכונות מנוהלות (MIG). ל-Cloud DNS אין צורך לדעת מה סטטוס התקינות של הקצוות העורפיים השונים. מאזן העומסים מטפל במשימה הזו.

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

לכתובת IP וירטואלית (VIP) אחת של Network Load Balancer עם העברה פנימית יכולות להיות כמה מכונות לקצה העורפי. אם למאזן עומסים פנימי של רשת עם תמיכה ב-passthrough אין מכונות לקצה העורפי, מערכת Cloud DNS עדיין מתייחסת אליו כאל מכונה תקינה. כדי שבדיקת התקינות תפעל כמו שצריך, צריך לציין לפחות מכונה אחת לקצה העורפי בהגדרות של מאזן העומסים.

כשנקודת הקצה מסומנת כלא תקינה, יכולים להתרחש התנאים הבאים:

  • אם יש כמה כתובות VIP שמוגדרות במדיניות, רק כתובות VIP תקינות יחזרו.

  • אם כל כתובות ה-VIP שמוגדרות בקטגוריית מדיניות מסוימת לא תקינות, המדיניות נכשלה. ההתנהגות הבאה חלה:

    • במדיניות WRR, Cloud DNS מחלק את התנועה באופן יחסי בין נקודות הקצה הפעילות הנותרות שמוגדרות במדיניות.
    • במדיניות למיקום גיאוגרפי שלא מופעלת בה הגבלת גישה, תעבורת הנתונים עוברת לנקודות קצה באזור הגיאוגרפי הקרוב ביותר לאזור המקור Google Cloud שמוגדר במדיניות.
    • במדיניות למיקום גיאוגרפי שבה מוגדר גיאופיינס, Cloud DNS מפיץ את התנועה לכתובת ה-VIP הקרובה ביותר לאזור המקור Google Cloud שמוגדר במדיניות.
    • במדיניות של חלוקת עומסים, Cloud DNS מעביר את התנועה לנקודות הקצה של הגיבוי שמוגדרות במדיניות.
    • אם כל הקטגוריות של המדיניות לא תקינות, Cloud DNS יפעל כאילו כל נקודות הקצה תקינות. התרחיש הזה עלול להוביל לתנועה שמופצת לנקודות קצה שלא מגיבות.

למידע נוסף על בדיקות תקינות למאזני עומסים פנימיים, ראו סקירה כללית על בדיקות תקינות.

בדיקות תקינות של נקודות קצה חיצוניות

בדיקות תקינות של נקודות קצה חיצוניות זמינות רק באזורים ציבוריים. חייבת להיות גישה לנקודות הקצה שרוצים לבדוק דרך האינטרנט הציבורי. נקודת הקצה שצוינה יכולה להיות כל כתובת IP חיצונית ויציאה, כולל כתובת VIP חיצונית גלובלית של Application Load Balancer, כתובת VIP חיצונית אזורית של Application Load Balancer, כתובת VIP חיצונית גלובלית של Network Load Balancer בשרת proxy, נקודות קצה מקומיות או כל נקודת קצה אחרת שאפשר לגשת אליה דרך האינטרנט הציבורי.

כדאי להשתמש בבדיקות תקינות של נקודות קצה חיצוניות בתרחישים הבאים:

  • כדי לנתב מחדש את התנועה למאזן עומסים חיצוני של אפליקציות (ALB) אזורי, אם קצה עורפי של מאזן עומסים חיצוני של אפליקציות (ALB) ברמה הגלובלית או קצה עורפי של מאזן עומסי רשת (Network Load Balancer) בשרת proxy חיצוני ברמה הגלובלית נמצא במצב לא תקין.
  • כדי לנתב מחדש את התנועה למאזן עומסים חיצוני אחר של אפליקציות (ALB) אזורי, אם הקצה העורפי של מאזן עומסים חיצוני ספציפי של אפליקציות (ALB) אזורי הופך ללא תקין.
  • כדי לעקוב אחרי תקינות נקודות קצה (endpoints) מקומיות או נקודות קצה אחרות שאפשר לגשת אליהן באינטרנט הציבורי.

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

Cloud DNS תומך בפרוטוקולים TCP, ‏ HTTP ו-HTTPS, עם ההגבלות הבאות:

  • אין תמיכה בשדה הבקשה של TCP.
  • אין תמיכה בשדה proxyHeader עבור HTTP,‏ HTTPS ו-TCP.

אין תמיכה בפרוטוקולים SSL,‏ HTTP/2 ו-gRPC.

בפרוטוקול TCP, Cloud DNS מנסה להתחבר לנקודת הקצה. בפרוטוקולים HTTP ו-HTTPS, Cloud DNS מאמת שנקודת הקצה מחזירה קוד תגובה HTTP‏ 200. אפשר גם להגדיר בדיקת תקינות מבוססת-תוכן, שבה Cloud DNS בודק שהתגובה מכילה מחרוזת ספציפית.

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

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

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

מרווח הזמן בין בדיקות התקינות

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

במסגרת בדיקת התקינות של נקודות קצה חיצוניות ב-Cloud DNS, מרווח הזמן בין הבדיקות צריך להיות בין 30 ל-300 שניות.

מדיניות ניתוב סבב רובין עם משקל ובדיקות תקינות

ב-Cloud DNS יש תמיכה בערכי משקלים מ-0 עד 1000, כולל. כשכוללים בדיקות תקינות, מתרחשים הדברים הבאים:

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

מדיניות ניתוב לפי מיקום גיאוגרפי ובדיקות תקינות

במדיניות ניתוב לפי מיקום גיאוגרפי עם בדיקות תקינות מופעלות, מתרחשים האירועים הבאים:

  • כשבמדיניות מוגדרות כמה כתובות IP, וכל כתובות ה-IP עוברות בדיקת תקינות, רק כתובות ה-IP תקינות יחזרו.
  • כשיש שילוב של כתובות IP עם בדיקת תקינות וכתובות IP ללא בדיקת תקינות, וכל כתובות ה-IP עם בדיקת תקינות נכשלות, Cloud DNS מחזיר את כל כתובות ה-IP שלא מוגדרת להן בדיקת תקינות. בתרחיש הזה, לא מתרחשת העברה אוטומטית ל-failover לאזור הגיאוגרפי הקרוב ביותר.

רישום ביומן של בדיקות תקינות

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

רישום ביומן של בדיקות התקינות מאפשר לכם:

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

מידע נוסף זמין במאמר מידע על רישום ביומן של בדיקות תקינות.

סוגי הרשומות הנתמכים במדיניות ניתוב DNS

כללי המדיניות של ניתוב DNS לא תומכים בכל סוגי הרשומות שנתמכים ב-Cloud DNS.

יש תמיכה בסוגי הרשומות הבאים:

סוג הרשומה תיאור
A כתובות IPv4 לבדיקות פנימיות (תחום פרטי) וחיצוניות (תחום ציבורי) .
AAAA כתובות IPv6 לבדיקות תקינות חיצוניות (באזור ציבורי).
CNAME שמות קנוניים. אין תמיכה בבדיקות תקינות.
MX רשומות MX (Mail Exchange). אין תמיכה בבדיקות תקינות.
SRV מארח/יציאה (RFC 2782). אין תמיכה בבדיקות תקינות.
TXT נתוני טקסט. אין תמיכה בבדיקות תקינות.

המאמרים הבאים