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

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

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

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

שיטות מומלצות לשימוש באזורים פרטיים ב-Cloud DNS

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

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

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

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

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

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

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

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

• ‫Google Cloud מקבל תגובות משרתי ה-DNS שלך רק אם הן מנותבות לרשת ה-VPC שממנה נוצרה השאילתה. עם זאת, לכל השאילתות מרשת VPC יש את אותו טווח כתובות IP‏ 35.199.192.0/19 כמקור. לכן, אי אפשר לנתב את התשובות בצורה נכונה אלא אם יש לכם סביבות נפרדות בפריסה מקומית.
• העברה יוצאת לא יכולה לעבור דרך חיבור של קישור בין רשתות VPC שכנות. לדוגמה, אם רשת VPC A מוגדרת עם Cloud VPN או Cloud Interconnect, רשת VPC B לא יכולה להשתמש בחיבור VPC Network Peering שלה לרשת VPC A כדי לשלוח שאילתות DNS לשרתי ה-DNS המקומיים.

איור 4. בעיה שקשורה לכמה רשתות VPC שמבצעות העברה יוצאת.

מומלץ להגדיר רשת VPC אחת לשליחת שאילתות לשרתי שמות מקומיים באמצעות העברה של תנועה יוצאת. לאחר מכן, רשתות VPC נוספות יכולות לשלוח שאילתות לשרתי השמות המקומיים על ידי טירגוט רשת ה-VPC המיועדת באמצעות אזור DNS של רשתות VPC מקושרות. השאילתות שלהם יועברו לשרתי שמות מקומיים בהתאם לסדר ההמרות של השמות ברשת ה-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 מבצעת חיפושים של אזור קישור ב-Cloud DNS ברשת VPC אחרת, שמכונה רשת הספק של DNS. משתמשים עם הרשאת IAM‏ dns.networks.targetWithPeeringZone בפרויקט של רשת היצרן יכולים ליצור שיוך DNS בין רשתות הצרכן והיצרן. כדי להגדיר DNS peering מרשת VPC של צרכן, צריך את תפקיד ה-DNS peer בפרויקט המארח של רשת ה-VPC של הספק.

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

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

איור 5. פירינג של DNS משמש לארגון כל האזורים של .internal במרכז.

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

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

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

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

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

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

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

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

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

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

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

איור 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 נפרדות.

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

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

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

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

איור 8. בארכיטקטורה היברידית אפשר להשתמש ברשת VPC מרכזית שמחוברת לרשתות VPC מסוג Hub.

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

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 מתוך המערכות המקומיות.

הערה: כשמשתמשים ב-Cloud VPN במקום בקישור בין רשתות VPC שכנות (peering) בין סביבותGoogle Cloud עם הארכיטקטורה הזו, חשוב לוודא שיש מכונה וירטואלית או מנהרת VPN בפרויקט המרכזי בכל אזור שבו נעשה שימוש בפרויקטים של רשתות מסוג Hub and Spoke. כך מוודאים שכל המכונות הווירטואליות יכולות לשלוח שאילתות לגבי רשומות באמצעות שיתוף DNS.

‫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.

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

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

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

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