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

בשני המקרים, חשבון שירות עם התפקיד אדמין 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 משרת מקומי

כדי לגשת לרשומות פרטיות שמתארחות בשרתי DNS ארגוניים מקומיים באמצעות Cloud 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 של קישור בין רשתות שכנות (peering). השאילתות שלהם יועברו לשרתי שמות מקומיים בהתאם לסדר פתרון השמות של רשת ה-VPC שצוינה. ההגדרה הזו מוצגת בארכיטקטורות לדוגמה של DNS היברידי.

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

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

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

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

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

אם משתמשים בשמות שנוצרו אוטומטית, צריך להשתמש ב-DNS Peering לאזורים פנימיים

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

איור 5. הצמדת DNS משמשת לארגון כל האזורים מסוג ‎ .internal במרכז.
איור 5. קישור בין רשתות שכנות (peering) של DNS משמש לארגון כל האזורים .internal במרכז.

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

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

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

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

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

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

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

  • ארכיטקטורה היברידית באמצעות רשת VPC מרכזית שמחוברת לרשתות VPC היקפיות: נעשה שימוש בקישור בין רשתות VPC שכנות (peering) כדי ליצור רשת VPC מרכזית שמחוברת לכמה רשתות VPC היקפיות עצמאיות.

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

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

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

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

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

  1. מגדירים את שרתי ה-DNS המקומיים כשרתי 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 המקומיים כשרתי DNS סמכותיים עבור corp.example.com.
  2. מגדירים אזור פרטי (לדוגמה, prod.gcp.example.com) ב-Cloud DNS בפרויקט המארח של רשת ה-VPC המשותפת של הייצור, ומגדירים את כל הרשומות של המשאבים באזור הזה.
  3. מגדירים אזור פרטי (לדוגמה, dev.gcp.example.com) ב-Cloud DNS בפרויקט המארח של רשת ה-VPC המשותפת של הפיתוח, ומגדירים את כל הרשומות של המשאבים באזור הזה.
  4. מגדירים מדיניות של שרת DNS בפרויקט המארח עבור רשת ה-VPC המשותפת של סביבת ה-Production, ומאפשרים העברת DNS נכנסת.
  5. ברשת ה-VPC המשותפת של סביבת הייצור, מגדירים תחום DNS להעברת corp.example.com לשרתי ה-DNS המקומיים.
  6. מגדירים אזור DNS שכנות (peering) מרשת ה-VPC המשותפת של הפיתוח לרשת ה-VPC המשותפת של הייצור עבור prod.gcp.example.com.
  7. מגדירים אזור DNS שכנות (peering) מרשת ה-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 מסוג Hub and Spoke

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

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

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

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

  1. מגדירים את שרתי ה-DNS המקומיים כשרתי DNS סמכותיים עבור corp.example.com.
  2. מגדירים אזור פרטי (לדוגמה, projectX.gcp.example.com) ב-Cloud DNS לכל רשת VPC מסוג Spoke, ומגדירים את כל הרשומות של המשאבים באזור הזה.
  3. מגדירים מדיניות של שרת DNS בפרויקט הרכזת עבור רשת ה-VPC של הרכזת כדי לאפשר העברת DNS נכנסת.
  4. ברשת ה-VPC של הרכזת, יוצרים תחום DNS פרטי בשביל corp.example.com ומגדירים העברה יוצאת לשרתי ה-DNS המקומיים.
  5. מגדירים אזור DNS של רשתות שכנות מרשת ה-VPC המרכזית לכל רשת VPC מסוג spoke עבור projectX.gcp.example.com.
  6. מגדירים אזור DNS של רשתות שכנות מכל רשת VPC מסוג Spoke לרשת VPC מסוג Hub עבור 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 פנימיים שנוצרו באופן אוטומטי, צריך לבצע peering בין כל אזור פרויקט מסוג 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.

  • כדי להגדיר את Cloud DNS בהגדרת DNS ציבורי של כמה ספקים, אפשר לעיין במאמר בנושא multi-provider-dns-with-clouddns.

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