דלג לתוכן הראשי
פרויקט זה בשלב בטא. מצאת באג? פתח issue ב-GitHub. יש שאלה או רעיון? שאל ב-Discussions — נשמח לשמוע ממך!
מה איכות התרגום בדף זה?

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

®IBM Quantum Platform הוא לוח הבקרה עבור מופעי IBM Quantum Compute Service ועומסי העבודה בחשבון ®IBM Cloud שלך, ומספק תצוגה פשוטה של ניהול גישה. לחשבון IBM Cloud של ארגון יכולים להיות מספר משתמשים ומספר מופעי Quantum Compute, כל אחד עם ההקצאה שלו. Identity and Access Management (IAM) שולט אילו משתמשים יכולים לגשת לאילו מופעי שירות, כך שאתה יכול לאפשר שיתוף פעולה תוך הגבלת נראות היכן שנדרש. ניהול גישה הופך רלוונטי יותר אם יש לך מופעי שירות בתוכניות בתשלום. ראה מבנה חשבון IBM Cloud לסקירה כללית של אופן ההתאמה בין חשבונות, משתמשים, מופעים וגישה. עיין בתיעוד ה-IAM של IBM Cloud לפרטים מלאים על מושגי ה-IAM המוזכרים במדריך זה, כגון קבוצות גישה, מדיניות, תפקידים, וקבוצות משאבים.

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

הערה

אם לארגון שלכם יש מספר חשבונות IBM Cloud — לדוגמה, חשבונות נפרדים לכל יחידה עסקית, כל אחד עם מופעי Quantum Compute משלו — תוכלו לקשר אותם תחת חשבון IBM Cloud Enterprise יחיד, שכולל חשבון ראשי אחד האחראי על החיוב וחשבון משנה אחד או יותר. כדי לחלק מחדש הקצאת Premium או Flex Plan בין חשבונות המשנה, צרו קשר עם תמיכת IBM Quantum דרך מרכז התמיכה של IBM Cloud. ראו את תיעוד חשבון IBM Cloud Enterprise לפרטים מלאים.

סקירה כללית​

הערה

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

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

הפרסונות הבאות מוזכרות במדריך זה:

  • משתמש: מישהו שמקבל גישה למשאבי Quantum Compute (מופעי שירות) ויכול לשתף פעולה עם משתמשים אחרים על משאבים אלה. גישת המשתמשים נשלטת על ידי מנהל מערכת, והם אינם יכולים ליצור או למחוק מופעי שירות.

  • מנהל Cloud: בעל חשבון IBM Cloud שמחזיק במשאבי IBM Quantum Compute ומנהל אילו משתמשים יכולים לגשת למשאבים אלה. כבעל המשאב, המנהל מחויב על כל שימוש בתשלום.

  • מנהל IDP: מנהל שמגדיר זהויות ותכונותיהן בספק זהויות (IDP).

מונחים​

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

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

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

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

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

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

    • אם אתה משתמש ב-IDP אחר, האם מנהל Cloud או מנהל ה-IDP מקצים משתמשים לקבוצות גישה?

    • אם מנהל ה-IDP מקצה משתמשים באמצעות כללים דינמיים, תזדקק למאפיין משתמש IDP מותאם אישית לשימוש כמפתח התאמה (לדוגמה, מאפיין team).

  • כמה מופעי שירות אתה צריך, ולמה כל אחד ישמש? תכנן את שמות המופעים שלך בקפידה. בכל פעם שאתה יוצר מופע שירות דרך ממשק המשתמש של IBM Quantum Platform, הפלטפורמה מבצעת קריאה נוספת ל-IAM מטעמך כדי ליצור קבוצת גישה תואמת (עם אותו שם כמו המופע, עם התוספת "Collaborators") שמעניקה גישת כתיבה למופע זה. לכן, שמות מופעים הופכים גם לשמות קבוצות גישה. שלב נוסף זה קורה רק כשאתה יוצר מופע דרך ממשק המשתמש של IBM Quantum Platform. הוא לא קורה אם אתה יוצר את המופע באמצעות Terraform, ה-CLI של IBM Cloud, או ה-API של IBM Cloud.

    • עומסי עבודה שייכים למופעי שירות, ומשתמשים שיש להם גישה למופע יכולים לראות את עומסי העבודה שלו.

    • מופעי שירות יכולים להתבסס על תוכניות שונות, ולאפשר גישה ל-Backends שונים והקצאות.

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

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

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

    • קבוצות גישה הן דרך נוחה ונפוצה לשליטה בגישת משתמשים למשאבי IBM Cloud. לכל מופע שירות שאתה יוצר דרך ממשק המשתמש של IBM Quantum Platform יש כבר קבוצת גישה משלו בשם "Collaborators". אפשר להשתמש בקבוצה זו כמו שהיא, או ליצור קבוצות גישה נוספות במסוף IBM Cloud כדי לקבץ משתמשים לפי צוות או עומס עבודה (לדוגמה, ml ו-finance) על פני מופע אחד או יותר. כל קבוצת גישה משתמשת בתפקיד מותאם אישית שמאפשר למשתמשים לגשת למופעי שירות או קבוצות משאבים ספציפיים. אם אינך צריך שקבוצת משתמשים תשתף את אותה גישה, אפשר גם להקצות גישה למשתמשים בודדים ישירות, ללא קבוצת גישה.

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

    הערה

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

שיקולים​

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

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

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

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

הערה

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

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

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

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

סימולציה של מבנים היררכיים​

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

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

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

ניתן להשתמש ב-Terraform כדי להגדיר הקצאה ומגבלות, וכן להגביל גישה ל-Backend עבור מופעי שירות מסוג quantum-computing. ראה תחילת העבודה עם Terraform ב-IBM Cloud למידע נוסף.

דוגמה:

resource "ibm_resource_instance" "instance1" {
name = "name"
service = "quantum-computing"
plan = "premium"
location = "us-east"
parameters = {
usage_allocation_seconds = "10" # Mandatory
usage_limit_seconds = "20" # Optional. If omitted, it can
# continue using time after reaching the allocation
backends = ["ibm_boston"] # Optional
}
}

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