תרחיש לדוגמה: בקרת גישה לאשכול Managed Service for Apache Spark בפרויקט אחר

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

תרחיש

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

לפני שמתחילים

כדי להבין את הפתרונות במקרה השימוש הזה, צריך להכיר את ההקשר הבא:

הנחות והיקף

הדרישות של התרחיש לדוגמה הזה הן:

  • מכונת Cloud Data Fusion פרטית. מטעמי אבטחה, יכול להיות שארגון ידרוש שימוש בסוג כזה של מופע.
  • מקור ויעד ב-BigQuery.
  • בקרת גישה באמצעות IAM, ולא בקרת גישה מבוססת-תפקידים (RBAC).

פתרון

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

ארכיטקטורה

בתרשימים הבאים מוצגת השוואה בין ארכיטקטורת הפרויקט ליצירת מופע של Cloud Data Fusion ולהרצת צינורות עיבוד נתונים כשמשתמשים באשכולות באותו פרויקט (בסיס) ובפרויקט אחר באמצעות ה-VPC של פרויקט הדייר.

ארכיטקטורת בסיס

בתרשים הזה מוצגת ארכיטקטורת הבסיס של הפרויקטים:

ארכיטקטורת דייר, לקוח ופרויקט Dataproc ב-Cloud Data Fusion.

בהגדרת הבסיס, יוצרים מכונת Cloud Data Fusion פרטית ומריצים צינור ללא התאמה אישית נוספת:

  • אתם משתמשים באחד מפרופילי החישוב המובנים
  • מקור הנתונים ויעד הנתונים נמצאים באותו פרויקט כמו המופע
  • לא הוקצו תפקידים נוספים לאף אחד מחשבונות השירות

מידע נוסף על פרויקטים של דיירים ולקוחות זמין במאמר בנושא רשתות.

ארכיטקטורה של תרחיש לדוגמה

בתרשים הזה מוצגת ארכיטקטורת הפרויקט כשמשתמשים באשכולות בפרויקט אחר:

ארכיטקטורת דייר, לקוח ופרויקט Dataproc ב-Cloud Data Fusion.

הגדרות אישיות

בקטעים הבאים מוצגות השוואות בין הגדרות הבסיס לבין הגדרות ספציפיות לתרחיש השימוש, להפעלת אשכולות של Managed Service for Apache Spark בפרויקט אחר באמצעות ה-VPC של פרויקט ברירת המחדל של הדייר.

בתיאורי תרחישי השימוש הבאים, פרויקט הלקוח הוא המקום שבו מופעל מופע Cloud Data Fusion, ופרויקט Managed Service for Apache Spark הוא המקום שבו מופעל אשכול Managed Service for Apache Spark.

מכונה ו-VPC של פרויקט דייר (tenant)

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

פרויקט של לקוח

בסיס להשוואה תרחיש שימוש
בפרויקט Google Cloud מגדירים ומריצים צינורות. כברירת מחדל, אשכולות של Managed Service for Apache Spark מופעלים בפרויקט הזה כשמריצים את צינורות הנתונים. בתרחיש לדוגמה הזה, אתם מנהלים שני פרויקטים. בדף הזה, פרויקט הלקוח הוא המקום שבו פועלת מכונת Cloud Data Fusion.‫
הפרויקט של Managed Service for Apache Spark מתייחס למיקום שבו מופעלים אשכולות של Managed Service for Apache Spark.

VPC של הלקוח

בסיס להשוואה תרחיש שימוש

מנקודת המבט שלכם (הלקוח), ה-VPC של הלקוח הוא המקום שבו Cloud Data Fusion ממוקם באופן לוגי.


נקודה חשובה:
פרטי ה-VPC של הלקוח מופיעים בדף 'רשתות VPC' בפרויקט.

עוברים אל VPC networks

 לא נדרשת הגדרה נוספת לתרחיש השימוש הזה.

רשת משנה של Cloud Data Fusion

בסיס להשוואה תרחיש שימוש

מנקודת המבט שלכם (הלקוח), רשת המשנה הזו היא המקום שבו Cloud Data Fusion ממוקם באופן לוגי.


נקודה חשובה:
האזור של רשת המשנה הזו זהה למיקום של מכונת Cloud Data Fusion בפרויקט הדייר. 		לא נדרשת הגדרה נוספת לתרחיש השימוש הזה.

רשת משנה של Managed Service for Apache Spark

בסיס להשוואה תרחיש שימוש

רשת המשנה שבה מופעלים אשכולות של Managed Service for Apache Spark כשמריצים צינור נתונים.


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

זוהי רשת משנה חדשה שבה מופעלים אשכולות של Managed Service for Apache Spark כשמריצים צינור נתונים.


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

מקורות ו-sinks

בסיס להשוואה תרחיש שימוש

המקורות שמהם הנתונים מחולצים והיעדים שאליהם הנתונים נטענים, כמו מקורות ויעדים של BigQuery.


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

Cloud Storage

בסיס להשוואה תרחיש שימוש

קטגוריית האחסון בפרויקט של הלקוח, שעוזרת להעביר קבצים בין Cloud Data Fusion לבין Managed Service for Apache Spark.


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

קטגוריות זמניות שמשמשות כמקורות וכ-sinks

בסיס להשוואה תרחיש שימוש

מאגרי זמניים שנוצרים על ידי תוספים למקורות וליעדים שלכם, כמו משימות טעינה שהופעלו על ידי התוסף BigQuery Sink.


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

קטגוריות שהן מקורות או יעדים של נתונים לתוספים

בסיס להשוואה תרחיש שימוש
קטגוריות של לקוחות, שאתם מציינים בהגדרות של תוספים, כמו התוסף Cloud Storage והתוסף FTP to Cloud Storage. לא נדרשת הגדרה נוספת לתרחיש השימוש הזה.

‫IAM: סוכן שירות של Cloud Data Fusion API

בסיס להשוואה תרחיש שימוש

כשמפעילים את Cloud Data Fusion API, התפקיד Cloud Data Fusion API Service Agent‏ (roles/datafusion.serviceAgent) מוקצה באופן אוטומטי ל חשבון השירות של Cloud Data Fusion, שהוא סוכן השירות הראשי.


נקודות עיקריות:
  • התפקיד מכיל הרשאות לשירותים באותו פרויקט כמו המופע, כמו BigQuery ו-Managed Service for Apache Spark. לכל השירותים הנתמכים, אפשר לעיין בפרטי התפקיד.
  • חשבון השירות של Cloud Data Fusion מבצע את הפעולות הבאות:
    • תקשורת של מישור הנתונים (תכנון וביצוע של צינור עיבוד הנתונים) עם שירותים אחרים (לדוגמה – תקשורת עם Cloud Storage,‏ BigQuery ו-Datastream בזמן התכנון).
    • הקצאת אשכולות של Managed Service for Apache Spark.
  • אם אתם משכפלים ממקור Oracle, צריך להקצות לחשבון השירות הזה גם את התפקידים Datastream Admin ו-Storage Admin בפרויקט שבו מתבצעת העבודה. בדף הזה לא מוסבר על תרחיש שימוש ברפליקציה.

בתרחיש השימוש הזה, מעניקים את התפקיד Cloud Data Fusion API Service Agent (סוכן שירות של Cloud Data Fusion API) לחשבון השירות בפרויקט Managed Service for Apache Spark. לאחר מכן, מעניקים את התפקידים הבאים בפרויקט הזה:

  • התפקיד Compute Network User
  • תפקיד עורך ב-Dataproc

‫IAM: חשבון שירות של Managed Service for Apache Spark

בסיס להשוואה תרחיש שימוש

חשבון השירות שמשמש להרצת צינור עיבוד הנתונים כמשימה באשכול Managed Service for Apache Spark. כברירת מחדל, זהו חשבון השירות של Compute Engine.


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

  • התפקיד Cloud Data Fusion Runner. התפקיד הזה מאפשר ל-Managed Service for Apache Spark לתקשר עם Cloud Data Fusion API.
  • התפקיד Dataproc Worker. התפקיד הזה מאפשר להריץ את המשימות באשכולות של Managed Service for Apache Spark.
נקודות עיקריות:
  • צריך להעניק לחשבון השירות של סוכן ה-API עבור השירות החדש את התפקיד 'משתמש בחשבון שירות' בחשבון השירות של Managed Service for Apache Spark, כדי שסוכן ה-API של השירות יוכל להשתמש בו להפעלת אשכולות של Managed Service for Apache Spark.

בדוגמה הזו לתרחיש שימוש מניחים שאתם משתמשים בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine ‏ (PROJECT_NUMBER-compute@developer.gserviceaccount.com) של פרויקט Managed Service for Apache Spark.


מקצים לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine בפרויקט Managed Service for Apache Spark את התפקידים הבאים.

  • התפקיד Dataproc Worker
  • תפקיד Storage Admin (או לכל הפחות ההרשאה `storage.buckets.create`) כדי לאפשר ל-Managed Service for Apache Spark ליצור קטגוריות זמניות ל-BigQuery.
  • התפקיד BigQuery Job User. התפקיד הזה מאפשר ל-Managed Service for Apache Spark ליצור משימות טעינה. כברירת מחדל, המשימות נוצרות בפרויקט Managed Service for Apache Spark.
  • התפקיד BigQuery Dataset Editor. התפקיד הזה מאפשר ל-Managed Service for Apache Spark ליצור מערכי נתונים בזמן טעינת הנתונים.

מקצים את התפקיד 'משתמש בחשבון שירות' לחשבון השירות של Cloud Data Fusion בחשבון השירות שמשמש כברירת המחדל של Compute Engine בפרויקט Managed Service for Apache Spark. צריך לבצע את הפעולה הזו בפרויקט Managed Service for Apache Spark.

מוסיפים את חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine של פרויקט Managed Service for Apache Spark לפרויקט Cloud Data Fusion. מקצים גם את התפקידים הבאים:

  • התפקיד 'צפייה באובייקט אחסון' כדי לאחזר ארטיפקטים שקשורים לעבודות של צינורות נתונים מהקטגוריה של Cloud Data Fusion Consumer.
  • תפקיד Cloud Data Fusion Runner, כדי שאשכול Managed Service for Apache Spark יוכל לתקשר עם Cloud Data Fusion בזמן שהוא פועל.

ממשקי API

בסיס להשוואה תרחיש שימוש
כשמפעילים את Cloud Data Fusion API, מופעלים גם ממשקי ה-API הבאים: מידע נוסף על ממשקי ה-API האלה זמין בדף APIs & services בפרויקט.

כניסה אל APIs & services

  • Cloud Autoscaling API
  • Dataproc API
  • Cloud Dataproc Control API
  • Cloud DNS API
  • Cloud OS Login API
  • Pub/Sub API
  • Compute Engine API
  • Container Filesystem API
  • Container Registry API
  • ‎Service Account Credentials API
  • Identity and Access Management API
  • Kubernetes Engine API

כשמפעילים את Cloud Data Fusion API, חשבונות השירות הבאים מתווספים אוטומטית לפרויקט:

  • סוכן שירות של Google APIs
  • Compute Engine Service Agent
  • Kubernetes Engine Service Agent
  • סוכן שירות של Google Container Registry
  • Google Cloud Dataproc Service Agent
  • סוכן שירות של Cloud KMS
  • חשבון שירות של Cloud Pub/Sub
 בתרחיש השימוש הזה, צריך להפעיל את ממשקי ה-API הבאים בפרויקט שמכיל את פרויקט Managed Service for Apache Spark, אם הם עדיין לא הופעלו:
  • Compute Engine API
  • Dataproc API
  • Cloud Resource Manager API

מפתחות הצפנה

בסיס להשוואה תרחיש שימוש

בהגדרת הבסיס, מפתחות ההצפנה יכולים להיות בניהול Google או CMEK .


נקודות עיקריות:

אם אתם משתמשים ב-CMEK, הגדרת הבסיס שלכם צריכה לכלול את הדברים הבאים:

  • המפתח צריך להיות אזורי, וצריך ליצור אותו באותו אזור שבו נוצרת מכונת Cloud Data Fusion.
  • מקצים לחשבונות השירות הבאים את התפקיד Cloud KMS CryptoKey Encrypter/Decrypter ברמת המפתח (לא בדף IAM במסוף Google Cloud ) בפרויקט שבו הוא נוצר:
    • חשבון שירות של Cloud Data Fusion API
    • חשבון השירות של Managed Service for Apache Spark, שהוא סוכן השירות של Compute Engine‏ (service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com) כברירת מחדל
    • סוכן שירות של Google Cloud Dataproc (service-PROJECT_NUMBER@dataproc-accounts.iam.gserviceaccount.com)
    • סוכן השירות של Cloud Storage (service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com)

בהתאם לשירותים שבהם נעשה שימוש בצינור עיבוד הנתונים, כמו BigQuery או Cloud Storage, צריך גם להעניק לחשבונות השירות את התפקיד Cloud KMS CryptoKey Encrypter/Decrypter:

  • חשבון השירות של BigQuery‏ (bq-PROJECT_NUMBER@bigquery-encryption.iam.gserviceaccount.com)
  • חשבון השירות של Pub/Sub‏ (service-PROJECT_NUMBER@gcp-sa-pubsub.iam.gserviceaccount.com)
  • חשבון השירות של Spanner (service-PROJECT_NUMBER@gcp-sa-spanner.iam.gserviceaccount.com)

אם אתם לא משתמשים ב-CMEK, לא צריך לבצע שינויים נוספים לתרחיש השימוש הזה.

אם משתמשים ב-CMEK, צריך להקצות את התפקיד Cloud KMS CryptoKey Encrypter/Decrypter לחשבון השירות הבא ברמת המפתח בפרויקט שבו הוא נוצר:

  • סוכן השירות של Cloud Storage (service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com)

בהתאם לשירותים שבהם נעשה שימוש בצינור עיבוד הנתונים, כמו BigQuery או Cloud Storage, צריך להעניק לחשבונות שירות אחרים את התפקיד Cloud KMS CryptoKey Encrypter/Decrypter ברמת המפתח. לדוגמה:

  • חשבון השירות של BigQuery‏ (bq-PROJECT_NUMBER@bigquery-encryption.iam.gserviceaccount.com)
  • חשבון השירות של Pub/Sub‏ (service-PROJECT_NUMBER@gcp-sa-pubsub.iam.gserviceaccount.com)
  • חשבון השירות של Spanner (service-PROJECT_NUMBER@gcp-sa-spanner.iam.gserviceaccount.com)

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

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