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

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

‫Cloud DNS תומך במדיניות הניתוב הבאה:

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

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

אי אפשר להגדיר מדיניות ניתוב DNS לאזורים הפרטיים הבאים:

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

מדיניות ניתוב WRR

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

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

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

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

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

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

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

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

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

כשמשביתים את הגדרת הגבול הווירטואלי ומתרחש כשל בבדיקת התקינות של מיקום גיאוגרפי ספציפי, התנועה עוברת אוטומטית למיקום הגיאוגרפי הקרוב הבא. עם זאת, כשהגידור הגיאוגרפי מופעל, המעבר האוטומטי הזה לא מתרחש. כשרת סמכותי, 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 של הגיבוי, כדי שתוכלו לוודא שהן פועלות. אפשר להגדיר את אחוז התנועה שמועבר לגיבוי כשבר בין 0 ל-1. אפשר להפעיל מעבר לגיבוי ידנית על ידי שליחת 100% מהתנועה לכתובות ה-VIP של הגיבוי. הערך האופייני הוא 0.1. אפשר להחיל בדיקות תקינות רק על מאזני עומסים פנימיים ועל נקודות קצה חיצוניות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כשיוצרים מדיניות ניתוב 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 שולח בקשה לבדיקת תקינות (probe) אחת כל 30 שניות.

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

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

‫Cloud DNS תומך במשקלים מ-0 עד 1,000, כולל. כשכוללים בדיקות תקינות, קורה הדבר הבא:

  • אם מגדירים כמה יעדים, ומשקל התנועה של כולם הוא 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 שלא הוגדרה להן בדיקת תקינות. בתרחיש הזה, המעבר האוטומטי לגיבוי למיקום הגיאוגרפי הקרוב הבא לא מתבצע.

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

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

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

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

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

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

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

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

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

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