העברת הגדרה קיימת של העברת DNS ב-Cloud DNS לנקודות קצה יוצאות

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

העברת הגדרה קיימת של העברת DNS ב-Cloud DNS

יש ארבעה שלבים להעברת הגדרה קיימת של העברת Cloud DNS לשימוש בנקודות קצה יוצאות:

הכנה

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

  1. יצירת תת-רשתות של שרתי proxy בלבד: אם עדיין אין לכם, בכל אזור שבו אתם מתכוונים לפרוס נקודת קצה יוצאת, צרו תת-רשת של שרתי proxy בלבד בגודל מינימלי של /26 (64 כתובות).
  2. זיהוי או יצירה של רשת משנה רגילה: בכל אזור שבו אתם מתכננים לפרוס נקודת קצה יוצאת, אתם צריכים לזהות או ליצור רשת משנה רגילה עם כתובת IPv4 פנימית זמינה בטווח ה-IP הראשי שלה.
  3. יצירת נקודות קצה יוצאות: יוצרים את נקודות הקצה היוצאות ומשייכים אותן לרשת ה-VPC, לאזור, לתת-הרשת הרגילה (--subnetwork=REGULAR_SUBNET) ולכתובת ה-IPv4 הפנימית הזמינה (--endpoint-ip=IP_ADDRESS_STRING) של היעד. Cloud DNS יוצר ומנהל באופן אוטומטי את המשאב של הקצאת ה-IP הסטטית, ומקשר את נקודת הקצה לתת-הרשת האזורית של שרתי proxy בלבד ברשת ה-VPC.

  4. עדכון של חומות האש והמסלולים המקומיים: מוודאים שלרשת המקומית יש מסלול חזרה לטווח כתובות ה-IP של תת-הרשת האזורית של שרתי ה-proxy בלבד. מוסיפים כללי חומת אש בסביבות המקומיות והחיצוניות כדי לאפשר תעבורת DNS נכנסת (יציאות UDP ו-TCP‏ 53) שמגיעה מטווח כתובות ה-IP של תת-הרשת האזורית של שרת ה-proxy בלבד.

אימות (אופציונלי)

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

  1. יצירת אזור העברה לבדיקה: יוצרים אזור העברה חדש וזמני לדומיין לבדיקה (לדוגמה, test.corp.example.com).
  2. הגדרת נקודות הקצה: מגדירים את אזור הבדיקה כך שישתמש בנקודות הקצה החדשות של Outbound.
  3. הפעלת מכונה וירטואלית לבדיקה: ברשת VPC רלוונטית, מפעילים מכונה וירטואלית זמנית לבדיקה.
  4. אימות הרזולוציה: מה-VM לבדיקה, משתמשים ב-dig או ב-nslookup כדי לשלוח שאילתה למארח באזור הבדיקה (לדוגמה, dig host.test.corp.example.com). מוודאים שמתקבלת תגובת DNS תקינה. בודקים ביומני שרת ה-DNS המקומי או החיצוני שהשרת קיבל את השאילתה מכתובת IP של מקור ברשת המשנה החדשה של שרת ה-proxy האזורי בלבד. בנוסף, צריך לוודא ביומנים של dns_query שהערך של jsonPayload.egressPath הוא OUTBOUND_ENDPOINT.

העברה לסביבת ייצור

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

  1. עדכון של אזורי העברה ומדיניות שרתים: בכל אזור העברה או מדיניות שרת שרוצים להעביר, עורכים את ההגדרות ומשנים את נתיב ההעברה מטווח ברירת המחדל 35.199.192.0/19 לנקודות הקצה של התעבורה היוצאת.
  2. מעקב אחרי פתרון הבעיות והתקינות: בודקים את יומני שאילתות ה-DNS של Cloud DNS (בודקים את jsonPayload.egressPath=OUTBOUND_ENDPOINT, jsonPayload.outboundEndpoint ו-jsonPayload.egressError) ואת מדדי המעקב הקיימים של האזורים שהועברו, כדי לוודא שהשאילתות נפתרות בהצלחה.
    • אפשר להשתמש ב-dns.googleapis.com/query/response_count כדי לעקוב אחרי נפח השאילתות וקודי הסטטוס של התשובות.
  3. אסטרטגיית העברה וחימום מראש בנפח גבוה:
    • זמן אחזור של התאמה אוטומטית לעומס (automatic scaling): זמן האחזור של ההתאמה האוטומטית לעומס (automatic scaling) של תשתית ה-proxy הבסיסית שמנוהלת על ידי Google הוא כ-10 דקות.
    • השקה הדרגתית: אם נפח השאילתות הכולל שלכם חורג מ-10,000 שאילתות לשנייה (QPS) לכל אזור, כדאי להעביר את האזורים בהדרגה (אזור אחד בכל פעם) כדי למנוע אובדן של שאילתות במהלך ההתאמה האוטומטית לעומס.
    • תמיכה בחימום מראש: בהעברות גדולות של אזור יחיד שחורגות מיד מ-10,000 שאילתות לשנייה (QPS) לכל אזור, מגבירים את התנועה בהדרגה (לדוגמה, 10%, 25%, 50% ואז 100%) או פונים לצוות ניהול החשבון או לתמיכה של Google Cloudלפני ההעברה המתוכננת, כדי לבקש חימום מראש של התשתית במהלך חלון הזמן לתחזוקה. בבקשה, ציינו את הפרטים הבאים:
      • מזהה פרויקט
      • אזורי היעד
      • מספר השאילתות המשוער לשנייה (QPS) בזמן שיא

הסרת המשאבים

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

  1. אישור ההעברה המלאה: מוודאים שכל אזורי ההעברה וכללי המדיניות של השרתים בפרויקט לא משתמשים בטווח ברירת המחדל 35.199.192.0/19.
    • בודקים את יומני ה-DNS המקומיים ומוודאים שאין תנועה שמגיעה מהטווח הזה במשך פרק זמן בטוח (לדוגמה, 24 שעות).
  2. הסרת הכלל הקודם של חומת האש: אחרי שמוודאים שכל תעבורת הנתונים הועברה לנקודות קצה יוצאות, אפשר להסיר בבטחה את הכלל של חומת האש המקומית שאפשר תעבורת DNS נכנסת מהטווח שמוגדר כברירת מחדל 35.199.192.0/19. לפני שמסירים או משנים את הכלל, חשוב לוודא שאין שירותים אחרים של Google Cloud שמשתמשים בו.

חזרה לגרסה קודמת

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

  1. החזרת מדיניות השרת או אזור ההעברה למצב הקודם: עורכים את המדיניות של השרת או האזור המושפע ומשנים את ההעברה שלו בחזרה לטווח ברירת המחדל של 35.199.192.0/19.
  2. שחזור כללי חומת האש: מוודאים שהכלל שמאפשר תנועת DNS נכנסת מ-35.199.192.0/19 עדיין פעיל. אל תסירו את הכלל הזה לפני שלב הניקוי של העברה מוצלחת.

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