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

בדף הזה מוסבר איך לנהל את בקרת הגישה כשפורסים ומריצים צינור (pipeline) שמשתמש באשכולות של 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.
לא נדרשת הגדרה נוספת לתרחיש השימוש הזה.

קטגוריות זמניות שמשמשות את המקור ואת היעד

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

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

  • התפקיד 'משתמש ברשת מחשוב'
  • תפקיד עורך ב-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. מקצים גם את התפקידים הבאים:

  • התפקיד Storage Object Viewer (צפייה באובייקט אחסון) כדי לאחזר ארטיפקטים שקשורים לעבודות של צינורות נתונים מהקטגוריה של Cloud Data Fusion Consumer.
  • תפקיד מריץ משאבי Cloud Data Fusion, כדי שאשכול 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
  • סוכן שירות של Cloud KMS
  • חשבון שירות של Cloud Pub/Sub
בתרחיש השימוש הזה, צריך להפעיל את ממשקי ה-API הבאים בפרויקט שמכיל את הפרויקט Managed Service for Apache Spark:
  • Compute Engine API
  • ‫Dataproc API (סביר להניח שהוא כבר מופעל בפרויקט הזה). ‫Dataproc Control API מופעל באופן אוטומטי כשמפעילים את Dataproc API.
  • ‫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 Agent (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)

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

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