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

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

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

היתרונות של שימוש בשמות DNS אזוריים

ב-Google Cloud יש שני סוגים של שמות DNS פנימיים: אזוריים וגלובליים.

DNS אזורי

שמות DNS אזוריים כוללים את השם של מכונת Compute Engine, את האזור שבו המכונה ממוקמת ואת הפרויקט שבבעלותו המכונה. השמות האלה נפתרים באזור ספציפי. כתוצאה מכך, my-vm.zone1.google.com ייחודי ל-zone1 ומייצג מופע שונה מ-my-vm.zone2.google.com. הבידוד הזה מספק יתרון מרכזי:

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

‫DNS אזורי הוא שיטת ברירת המחדל לפענוח DNS פנימי בארגונים שנוצרו אחרי 6 בספטמבר 2018.

DNS גלובלי

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

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

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

הגישה המומלצת למעבר מ-DNS גלובלי ל-DNS אזורי

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

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

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

הגבלות על העברה

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

גרסת glibc

המעבר ל-DNS אזורי מוסיף דומיין חדש לנתיב החיפוש. במקרים של מופעי Compute שמופעלת בהם מערכת הפעלה Linux או Unix ומשתמשים ב-glibc בגרסה 2.25 או בגרסה קודמת, יש מגבלה של 6 דומיינים לחיפוש. חריגה מהמגבלה הזו עלולה לגרום לבעיות.

  • מקרים מושפעים: ההגבלה הזו חלה על מכונות וירטואליות שמשתמשות בהפצות ישנות יותר של Linux או Unix.
  • מקרים שלא מושפעים: מקרים שבהם מערכות ההפעלה הבאות לא מושפעות:
    • Windows
    • מערכת הפעלה שמותאמת לקונטיינרים
    • ‫Debian 10 ואילך
    • Fedora CoreOS (גרסה 27 ואילך)
    • ‫RHEL 8 ואילך
    • ‫Ubuntu 18.04 ואילך
    • תמונות בהתאמה אישית שמשתמשות ב-glibc גרסה 2.26 ואילך

כדי לבדוק את הגרסה של glibc שבה נעשה שימוש במופע:

  1. מתחברים ל-VM של Linux.
  2. מריצים את הפקודה ldd --version.

אם המופע שלכם משתמש בגרסה glibc 2.25 או בגרסה מוקדמת יותר, בודקים את search domains:

  1. מתחברים ל-VM של Linux.
  2. מריצים את הפקודה cat /etc/resolv.conf.

גרסת מערכת ההפעלה

במערכות הפעלה מסוימות, כמו Windows Server 2003 וגרסאות קודמות, יש מגבלה של 15 תווים לשמות של מופעי מחשוב. מערכת DNS אזורית מוסיפה את המאפיין zonal לשם הדומיין המלא הפנימי (FQDN).

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

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

רשתות VPC משותפות

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

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