שיטות מומלצות לשימוש ב-Cloud DNS

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

קל יותר לאנשים ולאפליקציות להשתמש במערכת שמות הדומיין (DNS) כדי לפנות לאפליקציות ולשירותים, כי קל יותר לזכור שם והוא גמיש יותר מכתובות IP. בסביבה היברידית שכוללת פלטפורמות מקומיות ופלטפורמת ענן אחת או יותר, לעיתים קרובות צריך לגשת לרשומות DNS של משאבים פנימיים בסביבות שונות. באופן מסורתי, רשומות DNS מקומיות מנוהלות באופן ידני באמצעות שרת DNS סמכותי, כמו BIND בסביבות UNIX/Linux או Active Directory בסביבות Microsoft Windows.

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

עקרונות כלליים

מידע על מושגי DNS ב- Google Cloud

כשמשתמשים ב-DNS ב- Google Cloud, חשוב להבין את המערכות והשירותים השונים שזמינים ב- Google Cloudלפתרון בעיות ב-DNS ולשמות דומיין: Google Cloud

  • ‫Internal DNS הוא שירות שיוצר באופן אוטומטי שמות DNS למכונות וירטואליות ולמאזני עומסים פנימיים ב-Compute Engine.
  • ‫Cloud DNS הוא שירות שמספק תחום DNS עם זמינות גבוהה וזמן אחזור נמוך. הוא יכול לשמש כשרת DNS סמכותי לאזורים ציבוריים שגלויים באינטרנט, או לאזורים פרטיים שגלויים רק בתוך הרשת שלכם.
  • ‫שירות מנוהל ל-Microsoft Active Directory הוא שירות מוקשח עם זמינות גבוהה שמפעיל את Microsoft Active Directory, כולל בקר דומיין.
  • ‫Public DNS הוא שירות של Google שלא נכלל ב- Google Cloud . הוא פועל כמפענח DNS רקורסיבי ופתוח.
  • ‫Cloud Domains הוא רשם דומיינים שמאפשר לקנות, להעביר ולנהל דומיינים ב- Google Cloud. ‫Cloud Domains מאפשר לכם ליצור אינטראקציה עם מערכת רישום הדומיינים באמצעות API.

זיהוי בעלי עניין, כלים ותהליכים

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

  • מזהים את האדמין של שרתי ה-DNS הארגוניים של הארגון ויוצרים איתו קשר. אפשר לבקש מהם מידע על ההגדרות שנדרשות כדי למפות את ההגדרה המקומית לארכיטקטורה מתאימה ב-Google Cloud. מידע על שיטות לגישה לרשומות DNS זמין במאמר שימוש בהעברה מותנית לגישה לרשומות DNS מתוך רשת מקומית.Google Cloud
  • כדאי להכיר את תוכנת ה-DNS הנוכחית ולזהות את שמות הדומיינים שמשמשים לשימוש פרטי בארגון.
  • מזהים אנשי קשר בצוות הרשת שיכולים לוודא שהתעבורה לשרתי Cloud DNS מנותבת בצורה נכונה.
  • מומלץ להכיר את אסטרטגיית הקישוריות ההיברידית שלכם ואת הדפוסים והשיטות של סביבות היברידיות ומרובות עננים (multi-cloud).

יצירת תקן עקבי למתן שמות

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

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

  • יכולים להיות לכם שמות דומיין שונים לשרתים מקומיים ול-Google Cloud. בדפוס הזה משתמשים בדומיין נפרד לסביבות השונות – לדוגמה, corp.example.com לשרתים המקומיים ו-gcp.example.com לכל המשאבים ב- Google Cloud. אם אתם משתמשים בסביבות אחרות של ענן ציבורי, לכל אחת מהן יכול להיות תת-דומיין נפרד. זהו הדפוס המומלץ, כי אפשר להעביר בקשות בין סביבות.

    אפשר גם להשתמש בשמות דומיין נפרדים כמו example.com ו-example.cloud.

  • אפשר להגדיר את הדומיין Google Cloud כתת-דומיין של הדומיין שמכיל שרתים מקומיים. בדומיין example.com, אפשר להשתמש ב-corp.example.com בשרתים מקומיים וב- Google Cloud ב-gcp.corp.example.com. זהו דפוס נפוץ כשרוב המשאבים נשארים במקום.

  • אפשר להגדיר את הדומיין המקומי כתת-דומיין של הדומיין שמכיל רשומותGoogle Cloud . בדומיין example.com, Google Cloud אפשר להשתמש ב-corp.example.com ובסביבה מקומית אפשר להשתמש ב-dc.corp.example.com. זוהי תבנית לא נפוצה, אבל יכול להיות שארגונים דיגיטליים שפועלים בעיקר בענן ורק חלק קטן מהפעילות שלהם מתבצעת בשרתים מקומיים ישתמשו בה.

  • אפשר להשתמש באותו דומיין גם ב- Google Cloud וגם בפריסה מקומית. במקרה כזה, גם Google Cloud וגם המערכת המקומית משתמשים במשאבים שמשתמשים בדומיין corp.example.com. לא מומלץ להשתמש בתבנית הזו כי היא מקשה מאוד על ניהול רשומות בסביבה היברידית. אפשר להשתמש בה רק כשמשתמשים במערכת DNS סמכותית אחת.

בהמשך הדף הזה נעשה שימוש בשמות הדומיינים הבאים:

  • ‫example.com כשם דומיין לרשומות הציבוריות שלכם, בלי קשר למקום שבו הן מתארחות.
  • ‫corp.example.com כאזור שמתארח בשרת ה-DNS המקומי. באזור הזה מתארחות רשומות של משאבים מקומיים.
  • ‫gcp.example.com כתחום פרטי מנוהל ב-Cloud DNS שמארח רשומות של משאבי Google Cloud הדומיין.

איור 1 מציג הגדרה של שם דומיין שזהה ברשת המקומית וב- Google Cloud.

איור 1. הגדרה עקבית של שם הדומיין בכל הארגון.
איור 1. ההגדרה של שם הדומיין עקבית בכל הארגון.

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

בחירה של המקום שבו מתבצע פענוח DNS

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

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

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

שימוש בגישה היברידית עם שתי מערכות DNS סמכותיות

מומלץ להשתמש בגישה היברידית עם שתי מערכות DNS סמכותיות. בגישה הזו:

  • פענוח DNS סמכותי עבור הסביבה הפרטית Google Cloud שלכם מתבצע על ידי Cloud DNS.
  • פענוח DNS מוסמך למשאבים מקומיים מתארח בשרתי DNS מקומיים קיימים.

איור 2 מציג את הסידור הזה.

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

התרחיש שמוצג באיור 2 הוא תרחיש השימוש המומלץ. בהמשך הדף הזה מוסברים הפרטים הבאים:

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

שמירת פענוח ה-DNS בשרתים מקומיים

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

היתרונות של הגישה הזו:

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

עם זאת, יש לה כמה חסרונות:

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

העברת כל פענוח ה-DNS ל-Cloud DNS

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

היתרונות של הגישה הזו:

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