במאמר הזה מפורט מידע כללי על התחברות למקורות נתונים ממופעים ציבוריים או פרטיים של Cloud Data Fusion, מסביבות עיצוב וביצוע.
לפני שמתחילים
כדי להשתמש ברשתות ב-Cloud Data Fusion, צריך להבין את המושגים הבאים:
פרויקט של דייר (tenant)
Cloud Data Fusion יוצר פרויקט של דייר שמכיל את המשאבים והשירותים שנדרשים לניהול צינורות בשמכם, למשל כשמפעילים צינורות באשכולות של Managed Service for Apache Spark שנמצאים בפרויקט הלקוח שלכם.
פרויקט הדייר לא נחשף אליכם ישירות, אבל כשאתם יוצרים מכונה פרטית, אתם משתמשים בשם הפרויקט כדי להגדיר קישור (peering) בין רשתות VPC שכנות. לכל מופע פרטי בפרויקט הדייר יש רשת VPC ורשת משנה משלו.
בפרויקט יכולות להיות כמה מכונות Cloud Data Fusion. כשניגשים למופע בממשק המשתמש של Cloud Data Fusion או ב-Google Cloud CLI, אפשר לנהל את המשאבים והשירותים שהוא מכיל.
מידע נוסף זמין במאמרי העזרה בנושא Service Infrastructure על פרויקטים של דיירים.
פרויקט של לקוח
הלקוח יוצר את הפרויקט הזה והוא הבעלים שלו. כברירת מחדל, מערכת Cloud Data Fusion יוצרת בפרויקט הזה אשכול זמני של Managed Service for Apache Spark כדי להריץ את צינורות עיבוד הנתונים.
מכונת Cloud Data Fusion
מכונת Cloud Data Fusion היא פריסה ייחודית של Cloud Data Fusion, שבה מעצבים ומריצים צינורות עיבוד נתונים. אפשר ליצור כמה מכונות בפרויקט אחד ולציין את Google Cloud האזור שבו ייצרו את מכונות Cloud Data Fusion. בהתאם לדרישות ולמגבלות התקציב, אפשר ליצור מכונה שמשתמשת במהדורת Developer, Basic או Enterprise של Cloud Data Fusion. כל מופע מכיל פריסה ייחודית ועצמאית של Cloud Data Fusion, שכוללת קבוצה של שירותים שמטפלים בניהול מחזור החיים של צינורות, בתזמור, בתיאום ובניהול מטא-נתונים. השירותים האלה פועלים באמצעות משאבים שפועלים לאורך זמן בפרויקט דייר (tenant).
דיאגרמה של הרשת
בתרשימים הבאים מוצגים החיבורים כשיוצרים צינורות נתונים שמחלצים, משנים, משלבים, מצברים ומעלים נתונים ממקורות נתונים שונים מקומיים וממקורות נתונים בענן.
אפשר לראות את הדיאגרמות במאמרים בנושא שליטה ביציאה במופע פרטי וחיבור למקור ציבורי.
תכנון והפעלה של צינורות עיבוד נתונים
Cloud Data Fusion מספקת הפרדה בין סביבות העיצוב וההפעלה, כך שאפשר לעצב צינור עיבוד נתונים פעם אחת, ואז להפעיל אותו בכמה סביבות. סביבת העיצוב נמצאת בפרויקט הדייר, וסביבת ההפעלה נמצאת בפרויקט אחד או יותר של לקוחות.
לדוגמה: אתם מעצבים את צינור עיבוד הנתונים באמצעות שירותי Cloud Data Fusion, כמו Wrangler ו-Preview. השירותים האלה פועלים בפרויקט הדייר, שבו הגישה לנתונים נשלטת על ידי התפקיד Cloud Data Fusion Service Agent שמנוהל על ידי Google. לאחר מכן מריצים את צינור הנתונים בפרויקט הלקוח כדי להשתמש באשכול Managed Service for Apache Spark. בפרויקט של הלקוח, חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine שולט בגישה לנתונים. אתם יכולים להגדיר את הפרויקט כך שישתמש בחשבון שירות מותאם אישית.
מידע נוסף על הגדרת חשבונות שירות זמין במאמר חשבונות שירות של Cloud Data Fusion.
סביבת עיצוב
כשיוצרים מופע של Cloud Data Fusion בפרויקט הלקוח, Cloud Data Fusion יוצר באופן אוטומטי פרויקט נפרד של דייר שמנוהל על ידי Google, כדי להפעיל את השירותים שנדרשים לניהול מחזור החיים של צינורות ושל מטא-נתונים, את ממשק המשתמש של Cloud Data Fusion ואת כלי העיצוב כמו Preview ו-Wrangler.
פענוח DNS ב-Cloud Data Fusion
כדי לפתור שמות דומיין בסביבת זמן העיצוב כשמארגנים את הנתונים שמעבירים ל- Google Cloudומציגים אותם בתצוגה מקדימה, אפשר להשתמש ב-DNS Peering (זמין החל מ-Cloud Data Fusion 6.7.0). הוא מאפשר להשתמש בדומיין או בשמות מארחים כמקורות ויעדים, ולא צריך להגדיר אותם מחדש בתדירות גבוהה כמו כתובות IP.
מומלץ לבצע פענוח DNS בסביבת זמן העיצוב ב-Cloud Data Fusion, כשבודקים חיבורים וצופים בתצוגה מקדימה של פייפליינים שמשתמשים בשמות דומיין של שרתים מקומיים או שרתים אחרים (כמו מסדי נתונים או שרתי FTP), ברשת VPC פרטית.
מידע נוסף מופיע במאמרים בנושא DNS Peering וCloud DNS Forwarding.
סביבת הפעלה
אחרי שמאמתים ופורסים את צינור עיבוד הנתונים במופע, מפעילים את צינור עיבוד הנתונים באופן ידני, או שהוא מופעל לפי לוח זמנים או לפי טריגר של מצב צינור עיבוד הנתונים.
בין אם סביבת ההפעלה מוקצה ומנוהלת על ידי Cloud Data Fusion או על ידי הלקוח, הסביבה קיימת בפרויקט של הלקוח.
מופעים ציבוריים (ברירת מחדל)
הדרך הכי קלה להקצות מכונת Cloud Data Fusion היא ליצור מכונה ציבורית. היא מתאימה כנקודת התחלה ומספקת גישה לנקודות קצה חיצוניות באינטרנט הציבורי.
מכונה ציבורית ב-Cloud Data Fusion משתמשת ברשת ה-VPC שמוגדרת כברירת מחדל בפרויקט.
רשת ה-VPC שמוגדרת כברירת מחדל כוללת את המאפיינים הבאים:
- תת-רשתות שנוצרות אוטומטית לכל אזור
- טבלאות ניתוב
- כללים של חומת אש כדי להבטיח תקשורת בין משאבי המחשוב
רשתות בין אזורים
כשיוצרים פרויקט חדש, אחד היתרונות של רשת ה-VPC שמוגדרת כברירת מחדל הוא שהיא מאכלסת אוטומטית רשת משנה אחת לכל אזור באמצעות טווח כתובות IP מוגדר מראש, שמוצג כבלוק CIDR. טווח כתובות ה-IP מתחיל ב-10.128.0.0/20, ב-10.132.0.0/20, באזורים הגלובליים של Google Cloud .
כדי לוודא שמשאבי המחשוב שלכם מתחברים זה לזה באזורים שונים, רשת ה-VPC שמוגדרת כברירת מחדל מגדירה את המסלולים המקומיים שמוגדרים כברירת מחדל לכל רשת משנה. הגדרת נתיב ברירת המחדל לאינטרנט (0.0.0.0/0) מאפשרת לכם לקבל גישה לאינטרנט ולתעד תנועת רשת שלא מנותבת.
כללי חומת אש
רשת ה-VPC שמוגדרת כברירת מחדל מספקת קבוצה של כללי חומת אש:
| ברירת מחדל | תיאור |
|---|---|
ברירת המחדל היא 'מותר' icmp |
הפעלת פרוטוקול icmp למקור 0.0.0.0/0 |
| ברירת מחדל: אישור פנימי | הפעלת tcp:0-65535; udp:0-65535; icmp למקור 10.128.0.0/9, שכולל כתובות IP ממינימום 10.128.0.1 עד מקסימום 10.255.255.254 |
ברירת המחדל היא 'מותר' rdp |
הפעלת tcp:3389 למקור 0.0.0.0/0 |
ברירת המחדל היא 'מותר' ssh |
הפעלת tcp:22 למקור 0.0.0.0/0 |
הגדרות ברירת המחדל של רשת ה-VPC מצמצמות את הדרישות המוקדמות להגדרת שירותי ענן, כולל Cloud Data Fusion. בגלל חששות לגבי אבטחת הרשת, ארגונים לרוב לא מאפשרים להשתמש ברשת ברירת המחדל של VPC לפעולות עסקיות. בלי רשת ה-VPC שמוגדרת כברירת מחדל, אי אפשר ליצור מכונת Cloud Data Fusion שגלוי לכולם. במקום זאת, יוצרים מופע פרטי.
רשת ה-VPC שמוגדרת כברירת מחדל לא מעניקה גישה פתוחה למשאבים. במקום זאת, הגישה נשלטת על ידי ניהול הזהויות והרשאות הגישה (IAM):
- נדרש אימות זהות כדי להיכנס אל Google Cloud.
- אחרי שמתחברים, צריך הרשאה מפורשת (לדוגמה, תפקיד הצופה) כדי לראות את שירותי Google Cloud .
מכונות פרטיות
יש ארגונים שדורשים שכל מערכות הייצור שלהם יהיו מבודדות מכתובות IP ציבוריות. מכונה פרטית של Cloud Data Fusion עומדת בדרישה הזו בכל סוגי ההגדרות של רשת VPC.
Private Service Connect ב-Cloud Data Fusion
יכול להיות שיהיה צורך לחבר מופעים של Cloud Data Fusion למשאבים שנמצאים בפריסה מקומית, ב- Google Cloudאו אצל ספקי ענן אחרים. כשמשתמשים ב-Cloud Data Fusion עם כתובות IP פנימיות, נוצרים חיבורים למקורות חיצוניים דרך רשת ה-VPC בGoogle Cloud פרויקט. התעבורה ברשת לא עוברת דרך האינטרנט הציבורי. כשמעניקים ל-Cloud Data Fusion גישה ל-VPC באמצעות קישור בין רשתות VPC שכנות (peering), יש מגבלות שמתגלות כשמשתמשים ברשתות בהיקף נרחב.
באמצעות ממשקי Private Service Connect, Cloud Data Fusion מתחבר ל-VPC שלכם בלי להשתמש בקישור בין רשתות VPC. ממשק Private Service Connect הוא סוג של Private Service Connect שמאפשר ל-Cloud Data Fusion ליזום חיבורים פרטיים ומאובטחים לרשתות VPC של צרכנים. הפתרון הזה לא רק מספק גמישות וגישה נוחה (כמו קישור בין רשתות VPC שכנות), אלא גם הרשאה מפורשת ושליטה בצד הצרכן כמו ב-Private Service Connect. מידע נוסף זמין במאמר יצירת אירוע פרטי באמצעות Private Service Connect.
גישה לנתונים בסביבות עיצוב והרצה
במופע ציבורי, התקשורת ברשת מתבצעת דרך האינטרנט הפתוח, ולכן לא מומלץ להשתמש בו בסביבות קריטיות. כדי לגשת למקורות הנתונים בצורה מאובטחת, תמיד מריצים את צינורות הנתונים ממופע פרטי בסביבת ההרצה.
גישה למקורות
כשניגשים למקורות נתונים, למופעים ציבוריים ופרטיים:
- להתקשר ל- Google Cloud APIs באמצעות גישה פרטית ל-Google
- תקשורת עם סביבת ביצוע (Managed Service for Apache Spark) באמצעות VPC peering
בטבלה הבאה מוצגת השוואה בין מופעים ציבוריים ופרטיים במהלך העיצוב והביצוע של מקורות נתונים שונים:
| מקורות נתונים | מופע ציבורי של Cloud Data Fusion (בזמן העיצוב) |
Public Cloud Data Fusion Managed Service for Apache Spark (execution) |
מכונת Cloud Data Fusion פרטית (בזמן התכנון) |
שירות מנוהל פרטי של Cloud Data Fusion ל-Apache Spark (ביצוע) |
|---|---|---|---|---|
| Google Cloud source (אחרי שמעניקים הרשאות ומגדירים כללים לחומת האש) |
||||
| מקור מקומי (אחרי שמגדירים VPN/Interconnect, מעניקים הרשאות ומגדירים כללי חומת אש) |
||||
| מקור אינטרנט ציבורי (אחרי שנותנים הרשאות ומגדירים כללי חומת אש) |