שיטות מומלצות ל-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 ושמות דומיינים:

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

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

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

  • מאתרים את האדמין של שרתי ה-DNS הארגוניים של הארגון ויוצרים איתו קשר. צריך לבקש מהם מידע על ההגדרות הנדרשות למיפוי ההגדרות המקומיות לארכיטקטורה מתאימה ב-Google Cloud. מידע על שיטות לגישה לרשומותGoogle Cloud DNS זמין במאמר שימוש בהעברה מותנית כדי לגשת לרשומות DNS מהארגון.
  • כדאי להכיר את תוכנת ה-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 בארגון המקומי וב-gcp.corp.example.com ב- Google Cloud . זהו דפוס נפוץ כשרוב המשאבים נשארים בארגון.

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

העברת כל רזולוציית ה-DNS אל Cloud DNS

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

לגישה הזו יש את היתרונות הבאים:

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

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

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

שיטות מומלצות לעבודה עם תחומים פרטיים ב-Cloud DNS

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

שימוש באוטומציה לניהול תחומים פרטיים בפרויקט המארח של VPC המשותף

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

באיור 3 מוצג איך תחומים פרטיים מתארחים ברשת VPC משותפת.

איור 3. תחומים פרטיים שמתארחים ברשת VPC משותפת (לחיצה להגדלה).
איור 3. ההגדרה הזו מראה איך תחומים פרטיים מצורפים ל-VPC משותף.

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

לחלופין, אפשר להעביר את הגדרות ה-DNS למאגר קוד כמו Cloud Source Repositories, כתיאור של Terraform או Cloud Deployment Manager, ולקבל בקשות משיכה (pull request) מהצוותים.

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

הגדרת תפקידים ב-IAM לפי העקרון של הרשאות מינימליות

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

אם חשוב להפריד בין היכולת ליצור תחומי DNS פרטיים לבין היכולת ליצור תחומים ציבוריים, צריך להשתמש בהרשאה dns.networks.bindPrivateDNSZone.

שיטות מומלצות לאזורי העברה של DNS ולמדיניות השרתים

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

שימוש באזורי העברה לשליחת שאילתות לשרתים מקומיים

כדי לוודא שתוכלו לשלוח שאילתות לרשומות DNS בסביבה המקומית, צריך להגדיר תחום העברה לדומיין שבו אתם משתמשים במקור למשאבי הארגון (למשל corp.example.com). מומלץ להשתמש בגישה הזו במקום להשתמש במדיניות DNS שמפעילה שרת שמות חלופי. הוא שומר על הגישה לשמות DNS פנימיים של Compute Engine, ועדיין מתבצע תרגום של כתובות IP חיצוניות בלי קפיצה נוספת דרך שרת שמות מקומי.

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

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

שימוש בכללי מדיניות של שרת DNS כדי לאפשר שאילתות מהארגון

כדי לאפשר למארחים מקומיים לשלוח שאילתות לרשומות DNS שמתארחות בתחומים פרטיים של Cloud DNS (לדוגמה, gcp.example.com), צריך ליצור מדיניות של שרת DNS באמצעות העברה של DNS נכנס. העברה נכנסת של DNS מאפשרת למערכת לשלוח שאילתות לכל התחומים הפרטיים בפרויקט, וגם לכתובות IP פנימיות של DNS ולתחומים מקבילים.

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

פותחים חומות אש מקומיות Google Cloud כדי לאפשר תעבורת נתונים ב-DNS

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

  • מוודאים שחומת האש המקומית מעבירה שאילתות מ-Cloud DNS. Cloud DNS שולח שאילתות מטווח כתובות ה-IP 35.199.192.0/19. ‏DNS משתמש ביציאת UDP 53 או ביציאת TCP 53, בהתאם לגודל הבקשה או התשובה.

  • מוודאים ששרת ה-DNS לא חוסם שאילתות. אם שרת ה-DNS המקומי מקבל בקשות רק מכתובות IP ספציפיות, צריך לוודא שטווח כתובות ה-IP 35.199.192.0/19 נכלל.

  • מוודאים שאפשר להעביר תנועה מהארגון לכתובות ה-IP להעברה. במכונות של Cloud Router, מוסיפים נתיב מותאם אישית שפורסם לטווח כתובות ה-IP 35.199.192.0/19 ברשת ה-VPC לסביבה המקומית.

שימוש בהעברה מותנית כדי לגשת לרשומות DNS מהארגון

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

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

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

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

שימוש בקישור בין רשתות שכנות (peering) של DNS כדי למנוע העברה יוצאת מכמה רשתות VPC

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

איור 4. הבעיה מתרחשת כשמספר רשתות VPC מעבירות תעבורת נתונים מחוץ לרשתות שלהן.
איור 4. בעיה עם כמה רשתות VPC שמבצעות העברה יוצאת.

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

הסבר על ההבדל בין קישורי DNS לבין קישורי רשתות VPC

קישור בין רשתות VPC שכנות (peering) הוא לא אותו הדבר כמו קישור בין רשתות DNS שכנות (peering). קישור (peering) בין רשתות VPC שכנות מאפשר למכונות וירטואליות (VM) במספר פרויקטים להגיע זו לזו, אבל הוא לא משנה את פתרון השמות. המשאבים בכל רשת VPC עדיין פועלים לפי סדר הפתרון שלהם.

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

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

קישורי DNS מעבירים בקשות DNS באופן חד-כיווני, ולא נדרש קשר דו-כיווני בין רשתות VPC. רשת VPC שנקראת צרכן ה-DNS מבצעת חיפושים של תחום שיתוף (peering) ב-Cloud DNS ברשת VPC אחרת שנקראת בעלים ה-DNS. משתמשים עם הרשאת IAM dns.networks.targetWithPeeringZone בפרויקט של רשת היוצר יכולים ליצור קישורי DNS בין רשתות של צרכנים ויוצרים. כדי להגדיר קישוריות DNS מרשת VPC של צרכן, צריך את התפקיד 'קישוריות DNS' בפרויקט המארח של רשת ה-VPC של היצרן.

אם אתם משתמשים בשמות שנוצרו באופן אוטומטי, כדאי להשתמש בקישור DNS לתחומים פנימיים

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

איור 5. שימוש ב-DNS peering לארגון כל התחומים עם הסיומת ‎ .internal ברכז.
איור 5. שימוש ב-DNS peering לארגון כל המשאבים של .internal ברכז.

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

במדריך לפתרון בעיות ב-Cloud DNS מפורטות הוראות לפתרון שגיאות נפוצות שעשויות להתרחש במהלך ההגדרה של Cloud DNS.

ארכיטקטורות עזר ל-DNS היברידי

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

משתמשים בארכיטקטורת העזר שמתאימה לתכנון הרשת של VPC:

  • ארכיטקטורה היברידית באמצעות רשת VPC משותפת אחת: שימוש ברשת VPC אחת שמחוברת לסביבות מקומיות או מהן.

  • ארכיטקטורה היברידית באמצעות כמה רשתות VPC נפרדות: חיבור של כמה רשתות VPC לסביבות מקומיות באמצעות מנהרות VPN או צירופי VLAN שונים, ושיתוף אותה תשתית DNS מקומית.

  • ארכיטקטורה היברידית עם רשת VPC של צומת שמחוברת לרשתות VPC של קצוות: שימוש בקישור בין רשתות VPC כדי ליצור רשת VPC של צומת שמחוברת לכמה רשתות VPC של קצוות עצמאיות.

בכל מקרה, הסביבה המקומית מחוברת לרשתות ה-VPC Google Cloudבאמצעות מנהרה אחת או יותר של Cloud VPN או חיבורי Dedicated Interconnect או Partner Interconnect. לא משנה באיזו שיטת חיבור משתמשים לכל רשת VPC.

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

התרחיש לדוגמה הנפוץ ביותר הוא רשת VPC משותפת אחת שמחוברת לסביבה המקומית, כפי שמוצג באיור 6.

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

כדי להגדיר את הארכיטקטורה הזו:

  1. מגדירים את שרתי ה-DNS המקומיים כשרתי סמכות עבור corp.example.com.
  2. מגדירים תחום פרטי מוסמך (למשל, gcp.example.com) ב-Cloud DNS בפרויקט המארח של רשת ה-VPC המשותפת, ומגדירים את כל הרשומות של המשאבים באזור הזה.
  3. מגדירים מדיניות של שרת DNS בפרויקט המארח של רשת ה-VPC המשותפת כדי לאפשר העברה של נתוני DNS נכנסים.
  4. מגדירים תחום העברת DNS שמעביר את corp.example.com לשרתי ה-DNS המקומיים. רשת ה-VPC המשותפת צריכה לקבל הרשאה לשליחת שאילתות לאזור ההעברה.
  5. מגדירים העברה אל gcp.example.com בשרתי ה-DNS המקומיים, כך שתצביע על כתובת IP של מעביר נכנס ברשת ה-VPC המשותפת.
  6. מוודאים שתנועת DNS מותרת בחומת האש המקומית.
  7. במכונות של Cloud Router, מוסיפים לסביבה המקומית נתיב מודעה מותאם אישית לטווח 35.199.192.0/19.

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

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

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

איור 7. בארכיטקטורה היברידית אפשר להשתמש בכמה רשתות VPC נפרדות.
איור 7. בארכיטקטורה היברידית אפשר להשתמש בכמה רשתות VPC נפרדות.

כדי להגדיר את הארכיטקטורה הזו:

  1. מגדירים את שרתי ה-DNS המקומיים כשרתי סמכות עבור corp.example.com.
  2. מגדירים תחום פרטי (לדוגמה, prod.gcp.example.com) ב-Cloud DNS בפרויקט המארח של רשת ה-VPC המשותפת בסביבת הייצור, ומגדירים את כל הרשומות של המשאבים בתחום הזה.
  3. מגדירים תחום פרטי (לדוגמה, dev.gcp.example.com) ב-Cloud DNS בפרויקט המארח של רשת ה-VPC המשותפת לפיתוח, ומגדירים את כל הרשומות של המשאבים בתחום הזה.
  4. מגדירים מדיניות של שרת DNS בפרויקט המארח של רשת ה-VPC המשותפת בסביבת הייצור ומאפשרים העברה של DNS נכנס.
  5. ברשת ה-VPC המשותפת בסביבת הייצור, מגדירים תחום DNS להעברת corp.example.com לשרתי ה-DNS המקומיים.
  6. מגדירים תחום של קישוריות DNS מרשת ה-VPC המשותפת לפיתוח לרשת ה-VPC המשותפת בסביבת הייצור עבור prod.gcp.example.com.
  7. מגדירים תחום של קישורי DNS מרשת ה-VPC המשותפת בסביבת הייצור לרשת ה-VPC המשותפת בסביבת הפיתוח של dev.gcp.example.com.
  8. כדי להגדיר העברה נכנסת, מעבירים את הטיפול בבעיית הפתרון של gcp.example.com. לכתובות ה-IP הווירטואליות של העברה נכנסת ב-Cloud DNS בשרתי השמות המקומיים.
  9. מוודאים שחומת האש מאפשרת תנועה של DNS גם בחומת האש המקומית וגם בחומת האש שלGoogle Cloud .
  10. במכונות של Cloud Router, מוסיפים נתיב מודעה מותאם אישית לטווח כתובות ה-IP 35.199.192.0/19 ברשת ה-VPC המשותפת בסביבת הייצור לסביבה המקומית.

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

אפשרות נוספת היא להשתמש ב-Cloud Interconnect או ב-Cloud VPN כדי לחבר את התשתית המקומית לרשת VPC של צומת. כפי שמוצג באיור 8, אפשר להשתמש בקישור בין רשתות VPC שכנות (peering) כדי ליצור קישור בין רשת VPC לבין כמה רשתות VPC משניות. כל רשת VPC של זרוע מארחת תחומים פרטיים משלה ב-Cloud DNS. מסלולים מותאמים אישית ב-VPC Network Peering, יחד עם פרסום של מסלול מותאם אישית ב-Cloud Router, מאפשרים החלפה מלאה של מסלולים וקישוריות בין הרשת המקומית לכל רשתות ה-VPC של הענן. קישורי DNS פועלים במקביל לחיבורים של VPC Network Peering כדי לאפשר רזולוציית שמות בין סביבות.

הארכיטקטורה הזו מוצגת בתרשים הבא.

איור 8. בארכיטקטורה היברידית אפשר להשתמש ברשת VPC של צומת שמחוברת לרשתות VPC של קצוות באמצעות קישור בין רשתות VPC שכנות (VPC Network Peering).
איור 8. בארכיטקטורה היברידית אפשר להשתמש ברשת VPC של צומת שמחוברת לרשתות VPC של קצוות.

כדי להגדיר את הארכיטקטורה הזו:

  1. מגדירים את שרתי ה-DNS המקומיים כשרתי סמכות עבור corp.example.com.
  2. מגדירים תחום פרטי (לדוגמה, projectX.gcp.example.com) ב-Cloud DNS לכל רשת VPC של זרוע, ומגדירים את כל הרשומות של המשאבים באותו תחום.
  3. מגדירים מדיניות של שרת DNS בפרויקט הרכז של רשת ה-VPC המשותפת בסביבת הייצור כדי לאפשר העברה של DNS נכנס.
  4. ברשת ה-VPC של הצומת, יוצרים תחום DNS פרטי בשביל corp.example.com ומגדירים העברה של תעבורת נתונים יוצאת לשרתי ה-DNS המקומיים.
  5. מגדירים תחום של קישור בין רשתות שכנות (DNS peering) מרשת ה-VPC של הצומת לכל רשת VPC של הזרוע עבור projectX.gcp.example.com.
  6. מגדירים תחום של קישור בין רשתות שכנות (DNS peering) מכל רשת VPC של זרוע לרשת ה-VPC של הצומת עבור example.com.
  7. מגדירים העברה אל gcp.example.com בשרתי ה-DNS המקומיים כך שתצביע על כתובת IP של מעביר נכנס ברשת ה-VPC של הצומת.
  8. מוודאים שחומת האש מאפשרת תנועה של DNS גם בחומת האש המקומית וגם בחומת האש שלGoogle Cloud .
  9. במכונות של Cloud Router, מוסיפים נתיב מודעה מותאם אישית לטווח כתובות ה-IP 35.199.192.0/19 ברשת ה-VPC של הצומת לסביבה המקומית.
  10. (אופציונלי) אם אתם משתמשים גם בשמות ה-DNS הפנימיים שנוצרים באופן אוטומטי, צריך ליצור שיתוף בין כל אזור של פרויקט Spoke (לדוגמה, spoke-project-x.internal) לבין פרויקט ה-Hub, ולהעביר את כל השאילתות לגבי .internal מהארגון.

DNS ציבורי של ספקים מרובים באמצעות Cloud DNS

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

Google Cloud מציע פתרון בקוד פתוח שמבוסס על octoDNS, שעוזר להגדיר ולהפעיל סביבה עם כמה ספקי DNS. בפתרון ה-DNS עם כמה ספקים, Cloud DNS משמש כאחד מספקי ה-DNS שלכם בהגדרה של פעילות פעילה-פעילה (מומלצת) או פעילות פעילה-פסיבית, כדי להבטיח ארכיטקטורת DNS עם זמינות גבוהה. אחרי הפריסה של הפתרון, octoDNS מבצע סנכרון חד-פעמי וגם סנכרון שוטף בין תחומי ה-DNS הנוכחיים לבין תחומי ה-DNS המנוהלים שמתארחים ב-Cloud DNS. כשמעדכנים רשומות DNS ספציפיות, השינויים מועברים לאזורי ה-DNS התואמים שמתארחים ב-Cloud DNS, בלי צורך לבצע שינויים בצינורות עיבוד הנתונים של CI/CD.

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