ข้ามไปยังเนื้อหาหลัก

ข้อควรพิจารณาสำหรับการตั้งค่า IBM Quantum Platform สำหรับองค์กร

IBM Quantum® Platform คือแดชบอร์ดสำหรับ IBM Quantum Compute Service instances และ workloads ของ account IBM Cloud® ของคุณ และให้มุมมองที่เรียบง่ายของการจัดการการเข้าถึง account IBM Cloud ขององค์กรหนึ่งสามารถมีผู้ใช้หลายคนและ Quantum Compute instances หลายตัว โดยแต่ละตัวมีการจัดสรรของตัวเอง Identity and Access Management (IAM) ควบคุมว่าผู้ใช้คนใดสามารถเข้าถึง service instance ใดได้ ดังนั้นคุณสามารถเปิดใช้งานการทำงานร่วมกันในขณะที่จำกัดการมองเห็นในที่ที่จำเป็น การจัดการการเข้าถึงมีความเกี่ยวข้องมากขึ้นหากคุณมี service instances บนแผนแบบชำระเงิน ดู โครงสร้าง account IBM Cloud สำหรับภาพรวมว่า account, ผู้ใช้, instances และการเข้าถึงเชื่อมโยงกันอย่างไร อ้างอิง เอกสาร IBM Cloud IAM สำหรับรายละเอียดเต็มรูปแบบเกี่ยวกับแนวคิด IAM ที่อ้างอิงในคู่มือนี้ เช่น access groups, policies, roles และ resource groups

คู่มือนี้อธิบายการตัดสินใจและการแลกเปลี่ยนที่เกี่ยวข้องกับการตั้งค่าการเข้าถึงสำหรับองค์กรที่มี service instances หลายตัว — ตัวอย่างเช่น การกำหนด instance หนึ่งให้กับหนึ่งทีมหรือหนึ่ง workload

หมายเหตุ

ถ้าองค์กรของคุณมีบัญชี IBM Cloud หลายบัญชี — ตัวอย่างเช่น บัญชีแยกตามหน่วยธุรกิจ แต่ละบัญชีมี Quantum Compute instance เป็นของตัวเอง — คุณสามารถเชื่อมโยงบัญชีเหล่านั้นไว้ภายใต้บัญชี IBM Cloud Enterprise เดียว ซึ่งมีบัญชีหลักหนึ่งบัญชีที่รับผิดชอบการเรียกเก็บเงิน และบัญชีย่อยหนึ่งบัญชีหรือมากกว่า หากต้องการกระจาย allocation ของ Premium หรือ Flex Plan ใหม่ระหว่างบัญชีย่อย ให้ติดต่อฝ่ายสนับสนุน IBM Quantum ผ่าน IBM Cloud Support Center ดู IBM Cloud Enterprise account documentation สำหรับรายละเอียดทั้งหมด

ภาพรวม​

หมายเหตุ

IBM Cloud® มีหลายวิธีในการนำกลไกที่อธิบายในคู่มือนี้ไปใช้ ขั้นตอนส่วนใหญ่เป็นแบบทั่วไปของ IBM Cloud และไม่เฉพาะเจาะจงกับ Quantum Compute ยกเว้นรายละเอียด custom role

บุคคลที่เกี่ยวข้อง​

บุคคลต่อไปนี้ถูกกล่าวถึงในคู่มือนี้:

  • ผู้ใช้: คนที่ได้รับการเข้าถึง Quantum Compute resources (service instances) และอาจร่วมมือกับผู้ใช้คนอื่นบนทรัพยากรเหล่านี้ การเข้าถึงของผู้ใช้ถูกควบคุมโดยผู้ดูแลระบบและไม่สามารถสร้างหรือลบ service instances ได้

  • Cloud administrator: เจ้าของบัญชี IBM Cloud ที่เป็นเจ้าของ Quantum Compute resources และจัดการว่าผู้ใช้คนใดสามารถเข้าถึงทรัพยากรเหล่านี้ได้ ในฐานะเจ้าของทรัพยากร ผู้ดูแลระบบต้องรับผิดชอบค่าใช้จ่ายสำหรับการใช้ทรัพยากรแบบชำระเงิน

  • IDP administrator: ผู้ดูแลระบบที่กำหนด identities และคุณลักษณะของพวกเขาใน identity provider (IDP)

คำศัพท์​

คู่มือนี้ใช้คำศัพท์ต่อไปนี้:

  • Resource: คำทั่วไปของ IBM Cloud ที่หมายถึงออบเจกต์ที่สามารถจัดการผ่าน Cloud user interface, CLI หรือ API สำหรับคู่มือนี้ resource คือ Quantum Compute Service instance

  • Service instance: Service instance ใช้เพื่อเข้าถึง Cloud services โดยเฉพาะคอมพิวเตอร์ควอนตัม ผ่าน IBM Quantum Compute Service กำหนดผ่าน catalog สามารถกำหนด service instances หลายตัวตามแผนเดียวกันหรือต่างกัน ซึ่งให้การเข้าถึง Backend การคำนวณควอนตัมที่แตกต่างกัน ดูรายละเอียดที่ แผน IBM Cloud ที่ใช้ได้

วางแผนการตั้งค่า​

ก่อนตั้งค่า IBM Quantum Platform สำหรับองค์กร ต้องตัดสินใจสิ่งเหล่านี้:

  • จะกำหนด user identities อย่างไร สามารถตั้งค่าผู้ใช้ IBM Cloud, ผู้ใช้จาก identity provider (IDP) อื่น หรือทั้งสองอย่าง

    • ถ้าใช้ IDP อื่น Cloud administrator หรือ IDP administrator เป็นคนกำหนดผู้ใช้ให้กับ access groups?

    • หากผู้ดูแลระบบ IDP กำหนดผู้ใช้ผ่าน dynamic rules คุณจะต้องมี custom IDP user attribute เพื่อใช้เป็นคีย์การจับคู่ (ตัวอย่างเช่น attribute team)

  • คุณต้องการ service instances กี่ตัว และแต่ละตัวจะใช้เพื่ออะไร? วางแผนชื่อ instance ของคุณอย่างรอบคอบ ทุกครั้งที่คุณสร้าง service instance ผ่านส่วนติดต่อผู้ใช้ IBM Quantum Platform แพลตฟอร์มจะเรียก IAM เพิ่มเติมในนามของคุณเพื่อสร้าง access group ที่ตรงกัน (มีชื่อเดียวกับ instance โดยเติม "Collaborators" ต่อท้าย) ซึ่งให้สิทธิ์การเขียนแก่ instance นั้น ดังนั้นชื่อ instance จึงกลายเป็นชื่อ access group ด้วย ขั้นตอนเพิ่มเติมนี้เกิดขึ้นเฉพาะเมื่อคุณสร้าง instance ผ่านส่วนติดต่อผู้ใช้ IBM Quantum Platform เท่านั้น จะไม่เกิดขึ้นหากคุณสร้าง instance โดยใช้ Terraform, IBM Cloud CLI หรือ IBM Cloud API

    • Workloads เป็นของ service instances และผู้ใช้ที่มีการเข้าถึง instance สามารถดู workloads ของ instance นั้นได้

    • Service instances สามารถใช้แผนต่างกันได้ โดยอนุญาตให้เข้าถึง Backend ต่างกันและ allocations

  • ผู้ใช้คนใดต้องเข้าถึง service instances ใด?

  • ผู้ใช้ควรสามารถลบ workloads ได้หรือไม่ การเก็บ workloads ใน service instances ทำให้ติดตามค่าใช้จ่ายในการเรียกเก็บเงินได้ดีขึ้น

  • คุณจะใช้ access group ที่ถูกสร้างขึ้นโดยอัตโนมัติสำหรับแต่ละ instance สร้าง access group เพิ่มเติมของคุณเอง กำหนดการเข้าถึงให้กับผู้ใช้แต่ละคนโดยตรง หรือจัดระเบียบ instances เป็น resource groups?

    • Access groups เป็นวิธีที่สะดวกและใช้กันทั่วไปในการควบคุมการเข้าถึงของผู้ใช้ไปยังทรัพยากร IBM Cloud service instance ทุกตัวที่คุณสร้างผ่านส่วนติดต่อผู้ใช้ IBM Quantum Platform มี access group "Collaborators" ของตัวเองอยู่แล้ว คุณสามารถใช้ group นั้นตามที่เป็นอยู่ หรือสร้าง access group เพิ่มเติมใน IBM Cloud console เพื่อจัดกลุ่มผู้ใช้ตามทีมหรือ workload (ตัวอย่างเช่น ml และ finance) ข้าม instance หนึ่งตัวหรือมากกว่า access group แต่ละตัวใช้ custom role ที่อนุญาตให้ผู้ใช้เข้าถึง service instances หรือ resource groups เฉพาะ หากคุณไม่ต้องการให้กลุ่มผู้ใช้ใช้การเข้าถึงร่วมกัน คุณสามารถกำหนดการเข้าถึงให้กับผู้ใช้แต่ละคนโดยตรงได้เช่นกัน โดยไม่ต้องใช้ access group

      • หากคุณใช้ dynamic rules ที่อิงตาม IDP attributes เพื่อกำหนดผู้ใช้ให้กับ access groups หลีกเลี่ยงค่า attribute ที่เป็น substring ของกันและกัน ตัวอย่างเช่น หากคุณใช้ ml และ chemlab เป็นค่า attribute rule ที่จับคู่ ml จะจับคู่ chemlab ด้วย ทำให้เกิดการให้สิทธิ์การเข้าถึงมากกว่าที่คาดไว้โดยไม่ตั้งใจ ใช้ค่าที่ไม่ซ้ำกัน เช่น ml และ chem-lab หรือเพิ่ม prefix หรือ suffix เพื่อหลีกเลี่ยงการจับคู่ substring ที่ไม่ตั้งใจ

    • Resource groups ใช้เฉพาะเมื่อต้องการรักษาการแยก service instances อย่างชัดเจน เมื่อสร้าง service instance จาก IBM Quantum Platform คุณสามารถเลือกว่า instance นั้นจะอยู่ใน resource group ใด (และเพิ่ม tags) แต่คุณต้องใช้ IBM Cloud console เพื่อสร้างหรือจัดการ resource groups หากมีการสร้าง service instances เพิ่มเติมใน resource group ผู้ใช้ทั้งหมดที่มีการเข้าถึง resource group จะเห็นพวกมันโดยอัตโนมัติ โดยไม่ต้องอัปเดต access groups หากคุณเลือกใช้ resource groups ให้สร้าง access groups ก่อนแล้วจึงกำหนดให้กับ resource groups

    หมายเหตุ

    Service instance สามารถอยู่ใน resource group ได้เพียงหนึ่งเดียว และการกำหนดนั้นไม่สามารถเปลี่ยนแปลงได้หลังจากสร้าง instance แล้ว ดังนั้น resource groups อาจไม่ยืดหยุ่นเพียงพอถ้า service instances อาจต้องย้ายระหว่าง resource groups ในภายหลัง

ข้อควรพิจารณา​

ควรทำความเข้าใจข้อควรพิจารณาต่อไปนี้เมื่อตั้งค่าสภาพแวดล้อม

กำหนด roles ที่ละเอียดกว่า​

Custom roles สามารถใช้เพื่อการควบคุมการเข้าถึงที่ละเอียดกว่าได้ เช่น ผู้ใช้บางคนอาจต้องการการเข้าถึงแบบเต็มรูปแบบเพื่อทำงานบน service instances ในขณะที่คนอื่นอาจต้องการเพียงการเข้าถึงแบบอ่านอย่างเดียวสำหรับ service instances, programs และ workloads

เพื่อบรรลุเป้าหมายนั้น ให้กำหนด custom roles สองตัวที่แตกต่างกัน เช่น MLreader และ MLwriter ลบ actions cancel, delete และ update ทั้งหมดออกจาก MLreader custom role และรวม actions ทั้งหมดใน MLwriter custom role จากนั้นเพิ่ม roles ให้กับ access groups สองตัวที่แตกต่างกันตามลำดับ

หมายเหตุ

เมื่อใช้ dynamic rules นั่นคือเมื่อ IDP administrator จัดการการเข้าถึงผ่าน custom IDP user attributes อย่าใช้ IDP custom user attributes ที่เป็น substring ของกัน ตัวอย่างเช่น อย่าใช้ ml และ mlReader เนื่องจากการเปรียบเทียบ string ของ ml จะยอมรับ mlReader ด้วย สามารถใช้ MLreader และ MLwriter เพื่อหลีกเลี่ยงความขัดแย้งนี้

สำหรับตัวอย่าง ดูที่ ตั้งค่า custom roles

การเข้าถึง workload ร่วมกัน​

การเข้าถึงมีผลกับ service instances ดังนั้นผู้ใช้ที่มีสิทธิ์เขียนใน instance (รวมถึงผ่าน access group "Collaborators" ที่ถูกสร้างขึ้นโดยอัตโนมัติสำหรับ instances ที่สร้างโดยส่วนติดต่อผู้ใช้ IBM Quantum Platform) สามารถยกเลิก workloads ของตนเองได้ แต่ยังสามารถดูและยกเลิก workloads ของผู้ใช้คนอื่นใน instance นั้นได้ด้วย นี่คือฟังก์ชันของวิธีที่ IAM ทำงานและไม่สามารถเปลี่ยนแปลงได้

จำลองโครงสร้างแบบลำดับชั้น​

โดยค่าเริ่มต้น การเข้าถึงของแต่ละ service instance จะถูกจัดการอย่างเป็นอิสระ ตัวอย่างเช่น ผ่าน access group "Collaborators" ที่ถูกสร้างขึ้นโดยอัตโนมัติสำหรับ instances ที่สร้างผ่านส่วนติดต่อผู้ใช้ IBM Quantum Platform IAM ไม่มีลำดับชั้นของ groups ในตัว แต่คุณสามารถจำลองได้โดยการสร้าง access groups ที่อ้างอิง service instances ของหลายทีม ผู้ใช้ที่ต้องการการเข้าถึงในวงกว้างเพียงแค่ต้องถูกเพิ่มเข้าไปใน group "ระดับบนสุด" หนึ่ง group แทนที่จะต้องเพิ่มเข้าไปใน access group ของแต่ละทีมแยกกัน

การ deploy configuration อย่างสม่ำเสมอและทำซ้ำได้​

ขั้นตอนในคู่มือนี้สามารถทำให้เป็นอัตโนมัติสำหรับการจัดการผู้ใช้, service instances และการ mapping ระหว่างสิ่งเหล่านั้นอย่างสม่ำเสมอและทำซ้ำได้ ดูเอกสาร Terraform IBM Cloud® Provider สำหรับ templates

คุณสามารถใช้ Terraform เพื่อตั้งค่า allocation และ limits รวมถึงจำกัดการเข้าถึง backend สำหรับ service instances ของ quantum-computing ได้ ดูข้อมูลเพิ่มเติมได้ที่ Getting started with Terraform on 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
  }
}

ขั้นตอนถัดไป​

คำแนะนำ
แหล่งที่มา: IBM Quantum docs — อัปเดตเมื่อ 6 ส.ค. 2569
เวอร์ชันภาษาอังกฤษ บน doQumentation — อัปเดตเมื่อ 6 ส.ค. 2569
ปัญหาเกี่ยวกับเว็บไซต์หรือการแปล?ปัญหาเกี่ยวกับเนื้อหา? แก้ไขที่ IBM Quantum docs