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

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

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

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

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

    המסוף

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

    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 ‏ (v1) (roles/compute.instanceAdmin.v1) בפרויקט
  • אם מופע החישוב משתמש בחשבון שירות, אז: Service Account User (roles/iam.serviceAccountUser) on the service account or project

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

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

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

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

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

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

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

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

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

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

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

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

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

    כניסה אל Metrics Explorer

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

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

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

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

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

      מכונות Linux 

      sudo dhclient -v -r

      מכונות וירטואליות של Windows 

      ipconfig /renew

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

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

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

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

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

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

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

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

    כניסה לדף Logs Explorer

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

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

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

    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"
      • "תם הזמן הקצוב לתפוגת החיבור"
      • ‫"No such host is known" (לא ידוע על מארח כזה)

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

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

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

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

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

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

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

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

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

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

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

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

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

    • מופעי Linux: ‏ sudo dhclient -v -r
    • מכונה וירטואלית של Windows Server: ipconfig /renew

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

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

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

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

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

    • ב-Container-Optimized OS או ב-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 בפרויקטים שכוללים את הקונטיינרים ואת מכונות ה-Compute.

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

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