העברת הפרויקטים ל-DNS אזורי

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

לפני שמתחילים

  • אם עדיין לא עשיתם את זה, תצטרכו להגדיר אימות. אימות הוא תהליך שבו מאמתים את הזהות שלכם כדי לקבל גישה לממשקי API ולשירותים של Google Cloud . כדי להריץ קוד או דוגמאות מסביבת פיתוח מקומית, אפשר לבצע אימות ל-Compute Engine באחת מהדרכים הבאות:

    צריך לבחור את הכרטיסייה הרלוונטית לאופן שבו תכננתם להשתמש בדוגמאות בדף הזה:

    המסוף

    כשמשתמשים במסוף Google Cloud כדי לגשת לשירותים Google Cloud ולממשקי ה-API, לא צריך להגדיר אימות.

    gcloud

    1. התקינו את ה-CLI של Google Cloud. אחר כך, מאתחלים את ה-CLI של Google Cloud באמצעות הפקודה הבאה: 

      gcloud init

      אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

  • הגדרת אזור ותחום כברירת מחדל

    • REST

    כדי להשתמש בסביבת פיתוח מקומית בדוגמאות של API בארכיטקטורת REST שבדף הזה, צריך להשתמש בפרטי הכניסה שאתם נותנים ל-CLI של gcloud.

      התקינו את ה-CLI של Google Cloud.

      אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

    מידע נוסף מופיע במאמר אימות לשימוש ב-REST במסמכי האימות של Google Cloud .

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות להעברת פרויקטים לשימוש ב-DNS אזורי, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים:

  • העברת פרויקט לשימוש ב-DNS אזורי: עריכת פרויקטים (roles/resourcemanager.projectEditor) בפרויקט
  • העברת מכונות של Compute Engine ל-DNS אזורי בפרויקט:Compute Instance Admin (v1) (roles/compute.instanceAdmin.v1) בפרויקט
  • אם מופע החישוב משתמש בחשבון שירות, אז: Service Account User (roles/iam.serviceAccountUser) on the service account or project

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

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

ההרשאות הנדרשות

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

  • בודקים את שמות ה-DNS הגלובליים ואת המטא-נתונים של מכונות ה-Compute: compute.projects.get
  • הגדרת מטא-נתונים במכונה של Compute Engine: compute.instances.setMetadata
  • הגדרת מטא-נתונים ברמת הפרויקט: compute.projects.setCommonInstanceMetadata
  • אם מכונות וירטואליות לחישוב משתמשות בחשבונות שירות: iam.serviceAccounts.actAs

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

הגדרת מעקב אחרי כשלים בחיפוש DNS

מומלץ להפעיל יומני שאילתות DNS של Cloud DNS בפרויקט Compute Engine לפני שמעבירים ל-DNS אזורי. אתם יכולים להשתמש ביומנים כדי לעקוב אחרי שיעורי הכשלים ב-DNS הפנימי ולהשוות ביניהם לפני ואחרי המעבר ל-DNS פנימי לפי אזור. ‫Google ממליצה להפעיל את הרישום ביומן של שאילתות DNS לפחות 24 שעות לפני ההעברה, כדי ליצור נתונים בסיסיים לפני ההעברה.

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

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

בדיקה אם הפרויקט משתמש ב-DNS גלובלי כברירת מחדל

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

המסוף

  1. במסוף Google Cloud , נכנסים לדף Metadata של Compute Engine.

    מעבר אל Metadata

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

    • ‫GlobalDefault: בפרויקט מופעל DNS גלובלי.
    • ‫ZonalOnly: הפרויקט כולל DNS אזורי. אין צורך להעביר את הפרויקט הזה.

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

gcloud

מריצים את הפקודה הבאה ב-CLI של gcloud כדי לבדוק את הערך של vmDnsSetting.

gcloud compute project-info describe --project=PROJECT_ID --flatten="vmDnsSetting"

מחליפים את PROJECT_ID בשם הפרויקט.

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

  • ‫GLOBAL_DEFAULT: בפרויקט מופעל DNS גלובלי.
  • ‫ZONAL_ONLY: בפרויקט מופעל DNS אזורי. אין צורך להעביר את הפרויקט הזה.

REST

בודקים את הערך של vmDnsSetting באמצעות השיטה projects.get. בדוגמה הזו נעשה שימוש בפרמטר השאילתה fields כדי לכלול רק את השדות שרוצים לראות.

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID?fields=id,name,vmDnsSetting

מחליפים את PROJECT_ID במזהה הפרויקט.

הערך vmDnsSetting מציין אם הפרויקט משתמש ב-DNS גלובלי כברירת מחדל.

  • ‫GLOBAL_DEFAULT: בפרויקט מופעל DNS גלובלי.
  • ‫ZONAL_ONLY: בפרויקט מופעל DNS אזורי. אין צורך להעביר את הפרויקט הזה.

רשימת משימות למיגרציה של פרויקט

כדי לוודא שהמעבר של הפרויקט ל-DNS אזורי יהיה חלק, פועלים לפי השלבים הבאים:

  • בודקים אם יש שאילתות לא תואמות: מוודאים שבפרויקט אין שאילתות שלא תואמות ל-DNS אזורי. ‫Compute Engine מבצע את הניתוח הזה באופן אוטומטי על ידי הערכה של יומני שאילתות DNS מ-30 הימים הקודמים. אם הערכת היומן מסמנת שאילתות לא תואמות, צריך לפתור אותן לפי ההוראות במאמר Logs Explorer לפני שממשיכים.
  • בדיקת התאימות של הפרויקט: מוודאים בסביבה שלכם שאין תלות בארכיטקטורה הבסיסית, כמו גרסאות ספציפיות של מערכת ההפעלה Linux, שיכולות להשפיע על הפרויקט אחרי ההעברה. מידע נוסף זמין במאמר הנחיות לתאימות פרויקטים.
  • מעבר ל-DNS אזורי: החלת שינוי התצורה או עדכון קובצי Terraform כדי להעביר את הפרויקט.
  • אימות אחרי ההעברה: אחרי שתעברו לשימוש ב-DNS אזורי, תצטרכו לעקוב אחרי האפליקציות ולוודא שכל שאילתות ה-DNS הפנימיות נפתרות בצורה תקינה.

שימוש בניתוח שאילתות כדי לקבוע את מידת המוכנות של פרויקט להעברה

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

  • ‫zonal_dns_ready (שאילתות תואמות): המדד הזה מייצג את המספר הכולל של שאילתות במהלך תקופה של 100 ימים שאפשר לפתור בהצלחה באמצעות DNS אזורי.

  • ‫zonal_dns_risky (Incompatible queries or queries at-risk of failure post migration): המדד הזה מייצג את המספר הכולל של שאילתות שלא ניתן לפתור באמצעות DNS אזורי. השאילתות האלה בדרך כלל כוללות תקשורת בין אזורים או תרחישים אחרים שבהם הפתרון האזורי נכשל. חשוב לדעת: אם הערך של המדד הזה הוא לא אפס, הפרויקט עדיין לא מוכן להעברה. כדי לעבור ל-DNS אזורי, צריך לטפל בשאילתות האלה שלא תואמות.

כדי לראות את המדדים האלה, משתמשים בMetrics Explorer במסוף Google Cloud .

  1. במסוף Google Cloud , נכנסים לדף  Metrics explorer:

    עוברים אל Metrics Explorer

    אם משתמשים בשורת החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שכותרת המשנה שלה היא Monitoring.

  2. בצד ימין של סרגל הכלים שמכיל את השדה Select a metric, לוחצים על Code editor,‏ MQL או PromQL.

  3. אם שדה הקלט של השאילתה לא נקרא PromQL Query, צריך לבחור באפשרות PromQL בשדה Language.

  4. בשדה להזנת קלט של השאילתה, מזינים את הטקסט הבא בדיוק כמו שהוא מופיע:

    increase({"compute.googleapis.com/global_dns/request_count", monitored_resource="compute.googleapis.com/Location"}[1d])

  5. לוחצים על הלחצן הפעלת שאילתה.

    Google Cloud במסוף מוצג תרשים של שני המדדים (zonal_dns_ready ו-zonal_dns_risky) ומספר השאילתות התואם שבוצעו במהלך התקופה עבור כל מדד.

    צילום מסך של התרשים של מדדי השימוש הגלובליים ב-DNS.

  6. בודקים את הערך של המדד zonal_dns_risky.

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

העברת פרויקטים שתואמים ל-DNS אזורי

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

אחרי שמגדירים את ערך המטא-נתונים הזה, מכונות המחשוב:

  • אפשר לגשת אליהם רק באמצעות שמות ה-DNS האזוריים שלהם (INSTANCE_NAME.ZONE.c.PROJECT_ID.internal) כשמשתמשים בנתיבי חיפוש.
  • נתיבי החיפוש ברמת האזור וברמה הגלובלית נשמרים, אבל שמות ה-DNS הגלובליים, שלא כוללים את ZONE כחלק משם ה-DNS הפנימי, לא פועלים יותר.
  • אפשר להשתמש בשמות DNS גלובליים כדי לגשת רק למופעים אחרים באותו אזור ובאותו פרויקט.

כך עושים את זה:

  1. משתמשים במסוף Google Cloud , ב-CLI של gcloud או ב-REST כדי לשנות את רשומת המטא-נתונים vmDnsSetting של הפרויקט.

    המסוף

    1. כדי לעדכן את ההגדרה ברמת הפרויקט, במסוף Google Cloud , נכנסים לדף Metadata של Compute Engine.

      מעבר לדף 'מטא-נתונים בהתאמה אישית'

    2. לוחצים על עריכה.

    3. אם קיים מפתח עם הערך VmDnsSetting, הערך שלו ישתנה ל-ZonalOnly.

    4. אם לא קיים מפתח עם הערך VmDnsSetting, לוחצים על Add item.

      • בשדה Key (מפתח), מזינים vmDnsSetting.
      • בשדה ערך, מזינים ZonalOnly.

    5. כדי לסיים את השינוי של רשומות המטא-נתונים המותאמות אישית, לוחצים על שמירה.

    gcloud

    1. כדי לעדכן את הגדרת המטא-נתונים של הפרויקט הנוכחי, משתמשים בפקודה project-info add-metadata.

      gcloud compute project-info add-metadata \
     --metadata vmDnsSetting=ZonalOnly

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

      gcloud compute project-info describe --project=PROJECT_ID --flatten="vmDnsSetting"

      מחליפים את PROJECT_ID בשם הפרויקט שרוצים לשלוח אליו שאילתה.

    REST

    כדי לעדכן את הגדרת המטא-נתונים ברמת הפרויקט, יוצרים בקשת POST באמצעות השיטה projects.setCommonInstanceMetadata.

    1. אופציונלי: כדי לבצע נעילה אופטימית, אפשר לספק טביעת אצבע.

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

      אם לא תספקו טביעת אצבע, לא תתבצע בדיקת עקביות והבקשה projects.setCommonInstanceMetadata תצליח. אם משתמשים בשיטה instances.setMetadata, תמיד נדרשת טביעת אצבע.

      כדי לקבל את טביעת האצבע הנוכחית של פרויקט, קוראים ל-method‏ project.get.

      GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID

      הפלט אמור להיראות כך:

      {
  "name": "myproject",
  "commonInstanceMetadata": {
      "kind": "compute#metadata",
      "fingerprint": "FikclA7UBC0=",
      ...
  }
}

    2. יוצרים בקשת POST ל-method‏ projects.setCommonInstanceMetadata כדי להגדיר את צמד המפתח/ערך של המטא-נתונים:

      POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/setCommonInstanceMetadata

{
  "fingerprint": "FikclA7UBC0=",
  "items": [
    {
       "key": "vmDnsSetting",
       "value": "ZonalOnly"
    }
  ]
}

      מחליפים את PROJECT_ID במזהה הפרויקט.

    Terraform

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

    resource "google_compute_project_metadata_item" "vmdnssetting" {
  key     = "VmDnsSetting"
  project = "MyProject"
  value   = "ZonalOnly"
}

  2. אחרי שמגדירים את רשומת המטא-נתונים vmDnsSetting בפרויקט, צריך לרענן את הקצאת כתובות ה-DHCP בכל מופע בפרויקט. אפשר לרענן את ההקצאה באחת מהשיטות הבאות:

    • הפעלה מחדש של המופע
    • מחכים עד שתוקף החכירה יפוג

    • מריצים אחת מהפקודות הבאות:

      מכונות Linux 

      sudo dhclient -v -r

      מכונות של Windows 

      ipconfig /renew

  3. בודקים שהפרויקט משתמש ב-DNS אזורי.

תיקון שאילתות לא תואמות

אם פרויקט לא מוכן להעברה, סימן שב-30 הימים האחרונים בוצעה לפחות שאילתת DNS אחת שלא תואמת. שאילתות לא תואמות יכולות לכלול את המאפיינים הבאים:

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

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

כדי לתקן את כל השאילתות הלא תואמות, מומלץ להשתמש בשאילתה בשם הדומיין שמוגדר במלואו (FQDN) של המכונה המקורית של Compute Engine. הגישה הזו מבטיחה שרזולוציית השאילתות לא תופרע אחרי שתעבירו את הפרויקט לשימוש ב-DNS אזורי.

כדי לפתור בעיות של שאילתות לא תואמות:

  1. אתם יכולים להשתמש ב-Logs Explorer כדי לגשת לשימוש הגלובלי ב-DNS בכל המכונות של Compute Engine בפרויקט, ולשלוח שאילתות לגביו.

    כניסה לדף Logs Explorer

  2. בוחרים את הפרויקט שרוצים להעביר ל-DNS אזורי.

  3. מפעילים את המסננים של המשאב ושם היומן:

    1. לוחצים על כל המשאבים.
    2. בתיבת הדו-שיח Select resource (בחירת משאב), בוחרים באפשרות VM Instance (מכונה וירטואלית) ולוחצים על Apply (החלה).
    3. בחלונית Fields, בקטע Severity, בוחרים באפשרות Debug.
    4. לוחצים על All log names.

    5. בתיבת הדו-שיח Select log names (בחירת שמות יומנים), בוחרים באפשרות gdnsusage ולוחצים על Apply (החלה).

      שאילתה חלופית

      אפשר גם להזין את הערכים הבאים בשדה השאילתה:

       resource.type='gce_instance'
 log_name='projects/PROJECT_ID/logs/compute.googleapis.com/gdnsusage'

  4. בחלונית Query results (תוצאות השאילתה), לכל שאילתה יש שדה jsonPayload. כל שדה jsonPayload מכיל את הפרטים הבאים:

    • השם של מופע המחשוב של המקור, מזהה הפרויקט ושם האזור.
    • שם מופע היעד של Compute, מזהה הפרויקט ושם האזור.

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

      "To use Zonal DNS, update the Global DNS query sent from the source VM
INSTANCE_NAME.c.PROJECT_ID.internal to the following zonal
FQDN: INSTANCE_NAME.ZONE.c.PROJECT_ID.internal"

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

    בצילום המסך הבא מוצגים פרטי השדה jsonPayload בדף של מסוף Logs Explorer.

    צילום מסך של jsonPayload בתוצאות של שאילתת יומן gdnsusage.

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

    • שמות DNS פנימיים משרת המטא-נתונים: לא נדרשת פעולה כי שם ה-DNS שיוחזר ישתנה ל-FQDN אזורי מיד אחרי המעבר ל-DNS אזורי. אם שם ה-DNS נמצא במטמון, צריך לבצע עוד קריאה אחת כדי לעדכן את הערך במטמון.
    • שמות DNS פנימיים שמשמשים לגישה למכונות וירטואליות באזור אחר: אם יש לכם אפליקציה שמשתמשת בשמות DNS פנימיים למכונות וירטואליות באזורים שונים, אתם יכולים לשנות את מדיניות ה-DHCP או את קובץ ההגדרה כדי לכלול את האזור באזור אחר.
    • שם FQDN גלובלי שמוגדר בקוד: אם יש לכם אפליקציה שמשתמשת בשמות FQDN גלובליים שמוגדרים בקוד עבור מופעי המחשוב, אתם יכולים לעדכן את הקריאה בתוך האפליקציה כדי להשתמש בשם DNS פנימי או בשם FQDN אזורי במקום זאת. אפשר לבצע את השינוי הזה באמצעות שינוי בקוד או שינוי בהגדרות ב-Terraform.
    • מכונות וירטואליות בפרויקטים של שירותים שמשתמשים ברשת VPC משותפת: כדי לפתור שמות DNS של מכונות וירטואליות בפרויקטים של שירותים שמשתמשים ברשת VPC משותפת, צריך להשתמש בשמות דומיין מלאים (FQDN) של המכונות הווירטואליות לפי אזור.

  6. אחרי שמעדכנים את שאילתות ה-DNS הגלובליות כך שישתמשו ב-DNS אזורי, מבצעים את הפעולות הבאות:

    1. בדף Logs Explorer, שולחים שוב שאילתה על השימוש הגלובלי ב-DNS. אחרי שתתקנו את כל החסימות של שאילתות DNS גלובליות, לא אמורים להופיע יומני ניפוי באגים בתוצאות השאילתות.

    2. כדאי לבדוק שוב את מדד המעקב כדי לוודא שכל שאילתות ה-DNS הלא תואמות הוסרו.

צפייה ביומני DNS גלובליים ב-Logs Explorer

ב-Logs Explorer מוצגים בעיקר יומני DNS גלובליים של פרויקטים עם שאילתות שלא תואמות ל-DNS אזורי. היומנים האלה עוזרים לכם לזהות ולנתח את השאילתות הבעייתיות לפני המיגרציה.

אפשר גם להשתמש ב-Logs Explorer כדי לבצע את הפעולות הבאות בשאילתות לא תואמות:

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

בדיקה אם שינוי ב-DNS אזורי משפיע על הפרויקט

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

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

  1. תקשורת של מופע בשורת הפקודה

    משימה: מנסים לשלוח פינג ממופע אחד למופע אחר באמצעות ה-CLI של gcloud.

    gcloud compute ssh INSTANCE-A --command "ping INSTANCE-B"

    שגיאה פוטנציאלית: "לא ניתן לפענח את המארח" – המשמעות היא ש-INSTANCE-A לא יכול למצוא את כתובת ה-IP של INSTANCE-B.

    פתרון: צריך לעדכן את שם המארח שבו אתם משתמשים עבור INSTANCE-B לשם הדומיין שמוגדר במלואו (FQDN), שכולל את שם האזור: INSTANCE_NAME.ZONE.c.PROJECT_ID.internal

  2. תקשורת בין מכונות בשירותי Compute Engine

    משימה: אם אתם משתמשים בבדיקות תקינות עבור קבוצות מופעי מכונה מנוהלים (MIG) שמסתמכות על שמות DNS פנימיים, כדאי לבדוק אם בדיקות התקינות עוברות.

    שגיאה פוטנציאלית: 'בדיקת תקינות נכשלה' – השגיאה הזו מציינת שבדיקת התקינות לא יכולה להגיע ליעד שלה בגלל בעיות בפענוח DNS.

    פתרון: מוודאים שבבדיקת התקינות נעשה שימוש בשם הדומיין שמוגדר במלואו (FQDN) של מופע היעד, כולל שם האזור.

  3. תרחישים ספציפיים לאפליקציות

    אפליקציות רבות מסתמכות על DNS פנימי למשימות כמו:

    • חיבור למסדי נתונים (לדוגמה, Cloud SQL)

    • אינטראקציה עם תורי הודעות (לדוגמה, Pub/Sub)

    • שגיאות אפשריות: השגיאות משתנות בהתאם לאפליקציה, אבל יכולות לכלול:

      • "לא ניתן להתחבר אל SERVICE_NAME"
      • "חלף הזמן הקצוב לתפוגת החיבור"
      • "לא ידוע על מארח כזה"

    • פתרון: בודקים את ההגדרות של האפליקציה כדי לוודא שהיא משתמשת ב-FQDN (כולל שם האזור) כשמפנים לשירותים.

פתרון בעיות בתהליך ההעברה מ-DNS גלובלי ל-DNS אזורי

אם נתקלתם בבעיות בתהליך ההעברה, כדאי לעיין במדריך לפתרון בעיות.

חזרה לשימוש ב-DNS גלובלי

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

חזרה לשימוש ב-DNS גלובלי בפרויקט

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

  1. מוסיפים את הערך הבא למטא-נתונים של הפרויקט: vmDnsSetting=GlobalDefault.

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

  2. מוודאים שבאף אחד מהמכונות בפרויקט לא מוגדר ערך המטא-נתונים vmDnsSetting ל-ZonalOnly.

    gcloud compute instances describe INSTANCE_NAME --flatten="metadata.items[]"

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

  3. מרעננים את הקצאת כתובות ה-DHCP בכל מופע. כדי לרענן את ההקצאה, אפשר להפעיל מחדש את המכונה, להמתין עד שתוקף ההקצאה יפוג או להריץ את אחת מהפקודות הבאות במערכת ההפעלה של האורח:

    • מופעי Linux: ‏ sudo dhclient -v -r
    • מופע של Windows Server: ipconfig /renew

חזרה לשימוש ב-DNS גלובלי למופע

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

  1. מעדכנים את המטא-נתונים של המופע כך שיכללו את vmDnsSetting=GlobalDefault.

    במאמר הגדרה והסרה של מטא-נתונים בהתאמה אישית מוסבר איך מגדירים ערכי מטא-נתונים של מכונות Compute.

  2. כדי לכפות את השינוי בתצורת ה-DNS, מפעילים מחדש את הרשת של המופע באמצעות אחת מהפקודות הבאות:

    • במערכת הפעלה שמותאמת לקונטיינרים או ב-Ubuntu:

      sudo systemctl restart systemd-networkd

    • ב-CentOS, ב-RedHat EL, ב-Fedora CoreOS או ב-Rocky Linux:

      sudo systemctl restart network

      או

      sudo systemctl restart NetworkManager.service

    • ב-Debian:

      sudo systemctl restart networking

    • במערכות Linux עם nmcli:

      sudo nmcli networking off
sudo nmcli networking on

    • ב-Windows:

      ipconfig /renew

חזרה לשימוש ב-DNS גלובלי עבור קונטיינר

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

  1. מגדירים את הגדרת המטא-נתונים של הפרויקט vmDnsSetting לערך GlobalDefault בפרויקטים שבבעלותם הקונטיינרים והמכונות לחישוב.

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

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