דלג לתוכן הראשי

שיקולים להגדרת IBM Quantum Platform עבור ארגון

בארגון שבו אנשים עשויים לעבוד על מספר פרויקטים, ממשל IBM Quantum Platform עלול להיראות מורכב. עם זאת, ניהול הגישה יכול לשמש להפעלת שיתוף פעולה בין משתמשים ולהגבלת נראות המשתמשים והפרויקטים כשצריך. ניהול הגישה הופך רלוונטי יותר עם משאבי IBM Quantum Platform שאינם חינמיים — כלומר, מופעי שירות המשתמשים בתוכניות בתשלום (שהארגונים מחויבים עליהן).

סקירה כללית​

הערה

IBM Cloud® מספקת דרכים שונות ליישם את המנגנונים המתוארים במדריך זה. ישנן מספר דרכים להשיג את המטרות הללו. בנוסף, רוב השלבים במדריך זה גנריים ל-IBM Cloud ואינם ספציפיים ל-IBM Quantum Platform, למעט פרטי התפקיד המותאם אישית.

פרסונות מעורבות​

ישנן מספר פרסונות עיקריות המוזכרות במדריך זה:

  • משתמש: מישהו שמקבל גישה למשאבי IBM Quantum Platform (מופעי שירות) ויכול לשתף פעולה עם משתמשים אחרים על משאבים אלה. גישת המשתמשים נשלטת על ידי מנהל מערכת והם אינם יכולים ליצור או למחוק מופעי שירות.
  • מנהל Cloud: בעל חשבון IBM Cloud שמחזיק במשאבי IBM Quantum Platform ומנהל אילו משתמשים יכולים לגשת למשאבים אלה. כבעל המשאב, המנהל מחויב על כל שימוש בתשלום.
  • מנהל IDP: מנהל שמגדיר זהויות ותכונותיהן בספק זהויות (IDP).

מונחים​

מדריך זה משתמש במונחים הבאים:

  • משאב: מונח כללי ב-IBM Cloud המתייחס לאובייקט שניתן לנהל דרך ממשק המשתמש של Cloud, ה-CLI או ה-API. במדריך זה, משאב הוא מופע שירות של IBM Quantum Platform.

  • מופע שירות: מופע שירות משמש לגישה לשירותי Cloud — ובמיוחד, למחשבים קוונטיים. הוא מוגדר דרך הקטלוג. ניתן להגדיר מספר מופעי שירות על בסיס אותן תוכניות או תוכניות שונות, המאפשרות גישה ל-Backends שונים של מחשוב קוונטי. ראה תוכנית IBM Cloud הזמינה לפרטים.

  • פרויקט: יחידת קיבוץ המאפשרת למשתמשים לעבוד על אותם משאבים. מדריך זה משתמש בשני פרויקטים: ml ו-finance. ראה מבני פרויקט היררכיים לפרטים נוספים.

    הערה

    פרויקט זה אינו קשור למושג "פרויקט" בגרסה הקלאסית של IBM Quantum® Platform.

תכנן את ההגדרה שלך​

לפני שמגדירים את IBM Quantum Platform עבור הארגון שלך, עליך לקבל את ההחלטות הבאות:

  • כיצד מוגדרות זהויות המשתמשים? ניתן להגדיר משתמשי IBM Cloud, משתמשים מ-IDP אחר, או שניהם.

    • אם אתה משתמש ב-IDP אחר, האם מנהל Cloud או מנהל ה-IDP מקצים משתמשים למשאבי פרויקטים?
    • אם מנהל ה-IDP מקצה משתמשים לפרויקטים, אתה צריך מחרוזת לשימוש כמפתח, כגון project (שמדריך זה משתמש בו) להשוואת פרויקטים.

  • מהם הפרויקטים ואילו מופעי שירות ישתייכו לכל אחד? עליך לתכנן את שמות הפרויקטים בזהירות.

    • אל תהפוך שמות פרויקטים למחרוזות משנה של שם אחר. לדוגמה, אם אתה משתמש ב-ml וב-chemlab כשמות פרויקטים, ואחר כך מגדיר התאמת פרויקט ל-ml, היא תופעל על שני הערכים, ותעניק בטעות גישה רחבה יותר מהמצופה. במקום זאת, השתמש בשמות ייחודיים כמו ml ו-chem-lab. לחלופין, השתמש בתחיליות או סיומות כדי להימנע מהתאמות משנה בלתי מכוונות כאלה.
    • שימוש במוסכמות שמות יחד עם תחיליות או סיומות יכול לעזור לך לאפשר בקלות גישה לפרויקטים מרובים.
    • ניסויים קוונטיים (עבודות) שייכים למופעי שירות, ומשתמשים שיש להם גישה למופע יכולים לראות את עבודותיו.
    • מופעי שירות יכולים להתבסס על תוכניות שונות, ולאפשר גישה ל-Backends שונים.

  • אילו משתמשים צריכים גישה לאילו פרויקטים?

  • האם המשתמשים יוכלו למחוק עבודות? שמירת עבודות במופעי שירות מאפשרת מעקב טוב יותר אחר עלויות חיוב.

  • האם תשתמש בקבוצות גישה שמפנות ישירות למופעי שירות של IBM Quantum Platform או שתארגן שירותים בקבוצות משאבים?

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

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

שיקולים​

כדאי להבין את השיקולים הבאים בעת הגדרת הסביבה שלך.

הגדר תפקידים בעלי גרעינות גבוהה יותר​

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

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

הערה

בעת שימוש בכללים דינמיים, כלומר כאשר מנהל ספק הזהויות (IDP) מנהל גישה דרך תכונות משתמש מותאמות אישית של ה-IDP, אל תשתמש בתכונות משתמש מותאמות אישית של ה-IDP שהן מחרוזות משנה זו של זו. לדוגמה, אל תשתמש ב-ml וב-mlReader, שכן השוואת המחרוזת של ml תקבל גם את mlReader. ניתן להשתמש ב-MLreader וב-MLwriter כדי להימנע מהתנגשות זו.

לדוגמה להגדרת תפקידים מותאמים אישית, ראה יצירת קבוצות גישה לפרויקטים.

גישה לעומס עבודה משותף​

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

משאבי Cloud אחרים​

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

מבני פרויקט היררכיים​

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

שיטה זו יכולה להתאים מבנה היררכי. כלומר, היא יכולה להתאים לאופן שבו משתמשים עשויים להיות מוקצים למבנה הגישה Hub/Group/Project בגרסה הקלאסית של IBM Quantum® Platform. לדוגמה, קבוצה יכולה להיות קבוצת גישה המוקצית לכל מופעי השירות של פרויקטי הקבוצה. משתמשים שצריכים לקבל גישה לכל פרויקטי הקבוצה יצטרכו רק להתווסף לקבוצת הגישה של הקבוצה.

פריסה עקבית וחוזרת של ההגדרה​

ניתן לאוטמט את שלבי מדריך זה לניהול עקבי וחוזר של משתמשים, פרויקטים והמיפוי ביניהם. עיין בתיעוד ספק Terraform IBM Cloud® לתבניות.

השלבים הבאים​

המלצות