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

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

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

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

הכנה

בשלב ההכנה, לפני שמתחילים את ההעברה, יוצרים את רשתות המשנה לשרתי 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. עדכון חומות אש מקומיות: מוסיפים כללי חומת אש בסביבות המקומיות והחיצוניות כדי לאפשר תעבורת DNS נכנסת (יציאות 53 ב-UDP וב-TCP) שמגיעה מטווח כתובות ה-IP של תת-הרשת האזורית של שרת proxy בלבד.

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

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

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

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

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

  1. עדכון אזורי ההעברה ומדיניות השרת: לכל אזור העברה או מדיניות שרת שרוצים להעביר, עורכים את ההגדרה ומשנים את נתיב ההעברה מטווח ברירת המחדל 35.199.192.0/19 לנקודות הקצה שלכם להודעות יוצאות.
  2. מעקב אחרי פתרון הבעיות והתקינות: בודקים את יומני שאילתות ה-DNS של Cloud DNS ואת מדדי המעקב של האזורים שהועברו כדי לוודא שהשאילתות נפתרות בהצלחה.
    • אפשר להשתמש ב-dns.googleapis.com/query/response_count כדי לעקוב אחרי נפח השאילתות וקודי הסטטוס של התשובות.
  3. אסטרטגיית העברה בנפח גבוה וחימום מראש:
    • זמן אחזור של התאמה אוטומטית לעומס (automatic scaling): זמן האחזור של התחלת ההרצה של ההתאמה האוטומטית לעומס (automatic scaling) הוא כ-10 דקות לתשתית ה-proxy הבסיסית שמנוהלת על ידי Google.
    • השקה הדרגתית: אם נפח השאילתות המצטבר שלכם חורג מ-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 עדיין פעיל. אל תסירו את הכלל הזה לפני שלב הניקוי של העברה מוצלחת.

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