مشاركة مجموعات الرسومات الحاسوبية بين الفرق مع الحماية والإنصاف باستخدام Amazon SageMaker HyperPod

تحتاج فرق متعددة داخل نفس الشركة بشكل متزايد إلى الوصول المشترك إلى مجموعات الرسومات الثنائية المتقدمة (GPU) الباهظة لعمليات الذكاء الاصطناعي التوليدية، مع الحفاظ على حدود العزل والعدالة في الموارد واستقلالية التشغيل. لنفترض فرقة علوم البيانات تتدرب على نماذج اللغة الكبيرة، ومجموعة الرؤية الحاسوبية تنفذ أعمال الاستنتاج، وفريق البحث يختبر هياكل النماذج الجديدة. قد تحتاج كل منها إلى الوصول إلى نفس المجموعة. بدون بنية تحتية متعددة المشغلين (متعددة الفرق) مصممة بشكل جيد، تواجه المؤسسات استهلاكًا غير مُسيطر على الموارد، وانفصال ضعيف بين الفرق، وعدم قدرة على تحديد تكاليف GPU المشتركة على الفرق التي تتحملها، بالإضافة إلى أعباء إدارية تبطئ الابتكار.

خدمة Amazon SageMaker HyperPod هي خدمة ذكاء اصطناعي مصممة خصيصًا لتسهيل إدارة مجموعات الحوسبة على نطاق كبير لأعمال الذكاء الاصطناعي. توفر هذه الخدمة مجموعات قوية ومُحسّنة يتم تنظيمها بواسطة Amazon Elastic Kubernetes Service (Amazon EKS) أو Slurm، مما يسمح للمنظمات بتشغيل التدريب الموزع والتطوير التفاعلي واستنتاج النماذج على نطاق واسع. في الوقت نفسه، تقوم هذه الخدمة بإدارة صحة العقدة والاستعادة من الأخطاء وإدارة دورة حياة المجموعة تلقائيًا.

في هذا المقال، نقدم بنية مرجعية لبناء بيئة متعددة العمليات على Amazon SageMaker HyperPod مع EKS. تستخدم هذه البنية AWS IAM Identity Center للتحقق المركزي، ومجالات SageMaker AI لكل فريق لتوفير تجربة مستخدم مخصصة، وأجزاء Kubernetes لعزل الأعمال، وHyperPod Task Governance لتوزيع الموارد بشكل عادل، وتخصيص التكاليف على مستوى الأجزاء لتوفير رؤية للنفقات وفقًا للفريق. بحلول نهاية هذا المنشور، ستحصل على خطة واضحة لفرق متعددة لتبادل المعلومات بكفاءة بينما تكون كوليسكترا HyperPod EKS الواحد موجودة.

نظرة عامة على الهندسة المعمارية

يوضح الرسم البياني التالي البنية الهيكلية العليا لتنفيذ HyperPod EKS المخصص للعديد من الأشخاص. في هذا المثال، تشارك فريقان (فريق A وفريق B) مجمع HyperPod EKS واحدًا، حيث يعمل كل منهما داخل مساحة اسمية منفصلة خاصة به.

الشكل 1: هيكلة متعددة المشغلين على مستوى عالٍ لفريقين يشاركان كومة HyperPod EKS واحدة

تم تنظيم البنية الهندسية على شكل تدفق متعدد الطبقات من اليسار إلى اليمين، حيث يتم ربط هوية المستخدم من خلال ضوابط التفويض وصولاً إلى مساحات العمل المعزولة داخل المجمع.

المستخدمون والتحقق من الهوية

في الطرف الأيسر، يتفاعل المستخدمون الفرديون من كل فريق (المستخدم 1 من الفريق أ، والمستخدم 2 من الفريق ب) مع النظام عبر مسارين. يتم التحقق من الهوية في كلا المسارين من خلال بوابة AWS IAM Identity Center، والتي تتحد مع مزود الهوية الخارجي (مثل Microsoft Entra ID) الموجود في الطرف الأيسر السفلي.

المسار الأول يتم من خلال الوصول عبر CLI. يقوم المستخدمون بتوثيق حسابهم باستخدام aws sso login، مما يقودهم إلى بوابة Identity Center، ثم يحصلون على بطاقات اعتماد مؤقتة من مجموعة الصلاحيات الخاصة بفريقهم لتقديم المهام مباشرة إلى مجموعة EKS باستخدام kubectl. في الرسم البياني، تتدفق السهم الوردي من شاشة CLI عبر الأعلى مباشرة إلى مجموعة HyperPod EKS.

الطريق الثاني يتم عبر بوابة Identity Center مباشرة، حيث يختار المستخدمون تطبيق SageMaker Studio للانضمام إلى مجال SageMaker AI الخاص بفريقهم.

لكل فريق مجموعة أذونات مقابلة (مجموعة أذونات الفريق A، مجموعة أذونات الفريق B) تحتوي على سياسات إدارة الهوية والوصول في AWS (IAM) اللازمة لعمليات العمل باستخدام الأوامر اليدوية. يقوم Identity Center تلقائيًا بتوفير دور من IAM لكل مجموعة أذونات، والتي تظهر في الرسم البياني كـ TeamA-permissionset-role و TeamB-permissionset-role (مصنفة بـ “دور CLI/Console”). يعمل هذا الدور كموضوع IAM عند أن يقوم المستخدمون بتحقق الهوية من خلال aws sso login.

دوائر الذكاء الاصطناعي في ساجيمير

من بوابة Identity Center، يتم توجيه المستخدمين إلى مجال SageMaker AI الخاص بفريقهم. كل مجال (مجال SageMaker AI الفريق A ومجال SageMaker AI الفريق B) يوفر واجهة GUI خاصة بAmazon SageMaker Studio، ويتم تكوينه بدور حلقة تنفيذ خاص بالفريق (TeamA-role و TeamB-role) على التوالي). تُعتبر هذه المجالات واجهة العمل الميداني الرئيسية، بحيث يمكن للمستخدمين تقديم المهام من خلال الواجهة GUI (التي تظهر بالسهام الوردية المتجهة نحو EKS).

تحكم الوصول إلى EKS

على حدود EKS، تُرجم دفاتر الوصول أدوار IAM إلى صلاحيات Kubernetes. يوضح الرسم البياني دفاتر الوصول لـ TeamA-role و TeamB-role (أدوار تنفيذ Studio)، والتي تفوض الطلبات القادمة من واجهة GUI SageMaker Studio. يجب أيضًا تكوين دفاتر الوصول لأدوار CLI/Console المخصصة من Identity Center (TeamA-permissionset-role و TeamB-permissionset-role) لتفويض الطلبات القادمة عبر kubectl. ترتبط جميع دفاتر الوصول بسياسات التحكم في الوصول القائمة على الأدوار المُدار أو المخصصة (RBAC) (الممثلة بالرمز الرئيسي)، وتكون محدودة ضمن الفضاء المعين للفريق. ونتيجة لذلك، سواء كان الوصول قادم من Studio أو من CLI، يمكن للمستخدمين التفاعل فقط مع الموارد داخل فضاءهم الخاص.

حلقة HyperPod EKS

يتم تصوير المجموعة نفسها بطبقتين من منصات متقاطعة في الأعلى: HyperPod Observability (لمراقبة ولوحات العرض)، وHyperPod Task Governance (لإدارة حصص الحوسبة وأولويات التسريح). أسفل هذه الطبقات، يتم تقسيم المجموعة إلى Namespace A (الفريق أ) وNamespace B (الفريق ب). داخل كل مجال نطاق، يمكن للفرق تشغيل بيئات HyperPod Spaces الخاصة بهم (بيئات تطوير تفاعلية)، وعمليات HyperPod PyTorch (أعمال تشغيل تدريب موزعة)، ونقاط نهاية الاستنتاج في HyperPod (خدمة النماذج).

تخزين

تحت التجمع، تتضمن البنية التحتية مستويين للتخزين. المستوى الأول هو نظام ملفات متوافق مع POSIX (Amazon FSx for Lustre أو Amazon FSx for OpenZFS)، ومُنظَّم في مجلدات مشتركة لكل فريق (/fsx/TeamA، /fsx/TeamB) ومجلدات منزلية لكل مستخدم (/home/User1، /home/User2). أما المستوى الثاني فهو مكافئات Amazon Simple Storage Service (Amazon S3) مشتركة لكل فريق، ويُدار بواسطة دور تنفيذ IAM الخاص بالفريق.

تفصل هذه البنية الفريقين عن بعضهما بواسطة التحقق من الهوية والتصريح، حتى تنفيذ العملية، مع توزيع بنية تحتوي على رسومات جيميرات باهظة بشكل فعال.

التحقق من الهوية وضبط الوصول

أساس أي نظام متعدد المشغلين هو التحقق من الهوية بشكل قوي: التحقق من هوية المستخدمين قبل تفاعلهم مع أي مورد. في هذا التصميم، يعمل AWS IAM Identity Center كطبقة تحقق مركزية، حيث يتواصل مع مزود الهوية الخارجي لإدارة هويات المستخدمين وانتماءات المجموعات.

لماذا AWS IAM Identity Center

مركز هوية AWS IAM (خليفة للتسجيل الواحد لـ AWS) يوفر مكانًا واحدًا لإدارة هويات القوى العاملة في حسابات وتطبيقات AWS. بالنسبة لتركيب HyperPod متعدد المستأجرين، فهو يقدم عدة قدرات رئيسية:

• إدارة الهوية المركزية – بدلاً من الحفاظ على قواعد بيانات المستخدمين المنفصلة لكل خدمة AWS، يوفر Identity Center مصدرًا واحدًا للحقيقة لجميع هويات المستخدمين وانتماءاتهم إلى المجموعات.
• الاتحاد مع مزودي الهوية الحالية – تقوم معظم الشركات بالفعل بإدارة هويات موظفيها في أنظمة مثل Microsoft Entra ID (السابق Azure AD)، Okta، أو Ping Identity. يتم دمج Identity Center مع هذه المزودين، بحيث يمكن للمنظمات إعادة استخدام بنية الهوية الحالية دون تكرار حسابات المستخدمين.
• التكامل الأصلي مع SageMaker AI – تدعم فئات SageMaker AI مركز الهوية، بحيث يمكن للمستخدمين تسجيل الدخول إلى SageMaker Studio من خلال مزود الهوية المؤسسية الخاص بهم باستخدام التسجيل الواحد (SSO).
• وصول إلى حساب AWS – يمكن لمركز الهوية أيضًا منح المستخدمين وصولًا إلى حساب AWS الأساسي مع مجموعات صلاحيات محددة، والتي تدعم عمليات العملية باستخدام CLI بالإضافة إلى تجربة واجهة GUI في Studio.
• مطلوب لـ Amazon Managed Grafana – يستخدم Amazon Managed Grafana Identity Center كآلية اعتماد لل مستخدمي الفريق، مما يجعله الخيار الطبيعي عندما يحتاج الفريق أيضًا إلى الوصول إلى لوحة الرؤية لمراقبة أعمالهم.

تعرف أكثر: ما هو مركز الهوية IAM؟

تكوين مركز الهوية باستخدام مزود الهوية الخارجي

في هذه البنية الإرشادية، نستخدم Microsoft Entra ID كمزود الهوية الخارجية، على الرغم من أن نفس النمط ينطبق على معظم مزودي لغة التحقق الأمني القياسية SAML 2.0.

يتضمن التكوين:

1. هيكل المجموعات في مزود الهوية – في Entra ID، قم بإنشاء مجموعات تتوافق مع فرقك التنظيمية. في مثالنا، نحدد ثلاث مجموعات: TeamA، TeamB، وAdmin. تحتوي كل مجموعة على المستخدمين الذين ينتمون إلى تلك الفريق (على سبيل المثال، user1-teamA@example.com في مجموعة TeamA).
2. توفير SCIM – تمكين مزامنة SCIM (نظام إدارة الهوية عبر الأجهزة المختلفة) بين Entra ID وAWS IAM Identity Center. يوفر SCIM توفير وتحرير المستخدمين والمجموعات تلقائيًا. عند إضافة مستخدم جديد إلى مجموعة TeamA في Entra ID، يتم مزامنةه تلقائيًا مع Identity Center، ويحصل على الحقوق المناسبة دون أي تدخل يدوي.
3. التحقق من الهوية بناءً على SAML – قم بتكوين اتحاد SAML 2.0 بحيث عندما يقوم المستخدمون بالتحقق من هويتهم، يفعلون ذلك ضد Entra ID. يعمل Identity Center كمزود الخدمة، ويثق بالادعاءات القادمة من وحدات Entra ID الخاصة بك.

به هذا التكوين، يمكنك إدارة عضوية الفرق (وهي التي تؤثر على جميع قرارات التفويض اللاحقة) في دليل الشركة الخاص بك، ويتوزع ذلك تلقائيًا إلى AWS.

تُظهر الصورة التالية مثالًا على كيفية تمثيل الفرق التنظيمية في Microsoft Entra ID، حيث توجد مجموعات مخصصة لـ TeamA، TeamB، وAdmin.

الشكل 2: الفرق التنظيمية المعبر عنها كمجموعات في Microsoft Entra ID

ثم، تُظهر الصورة التالية المجموعات المقابلة في AWS IAM Identity Center، وقد تم تخصيصها تلقائيًا من Entra ID من خلال مزامنة SCIM.

الشكل 3: المجموعات المقابلة في AWS IAM Identity Center، المُوفرة من خلال SCIM

تعلم المزيد: ربط مزود الهوية الخارجي · ملف SCIM وتنفيذ SAML 2.0

التفويض

بعد إنشاء المصادقة، يكون الطبقة التالية هي التفويض: التحكم في الأفعال التي يمكن لكل فريق القيام بها عبر خدمات AWS وعمود Kubernetes. يعمل التفويض في هذا النموذج الهندسي على مستويين: IAM للوصول على مستوى الخدمة، وRBAC في Kubernetes للوصول على مستوى العمود.

أدوار IAM لكل فريق

كل فريق يحتاج إلى دور خاص في IAM يشمل الصلاحيات على مستوى AWS اللازمة لعمليات الذكاء الاصطناعي والتعلم الآلي (ML). تُعَدّ هذه الأدوار دور تنفيذ مجال الذكاء الاصطناعي في SageMaker وتحدد الخدمات التي يمكن للفريق الوصول إليها على AWS.

يجب أن تشمل وظيفة IAM النموذجية للفريق سياسات تمنح الوصول إلى:

• أمازون ساجيميسر ماتش أيه – لإدارة مجموعات هيبربود، خوادم تتبع ميلوفلو، والموارد الأخرى لساجيميسر ماتش أيه من خلال واجهة ساجيميسر ماتش أيه أيه.
• Amazon S3 – لقراءة مجموعات البيانات التدريبية وكتابة ملفات النموذج والنقاط التحقق والسجلات. قم بتحديد هذه الصلاحيات على بادئات الحاوية المخصصة للفريق.
• أمازون كلاودوويش – لعرض السجلات والمقاييس المتعلقة بأعمال الفريق.
• Amazon EKS – وتحديدًا، صلاحيات eks:AccessKubernetesApi وeks:MutateViaKubernetesApi، والتي يحتاج GUI لـ SageMaker Studio إلىها لإجراء استدعاءات API لكيبنوس على نفقة المستخدم (على سبيل المثال، عرض الفضاءات أو تقديم المهام).

يجب أن تشمل سياسة الثقة في كل دور IAM sagemaker.amazonaws.com كطرف موثوق، حتى يمكن لSageMaker AI أخذ الدور نيابة عن المستخدمين عند استخدامهم لـ Studio. إذا كنت تخطط لاستخدام نفس دور التنفيذ كارتباط Identity مع Pod EKS للأعمال العملية داخل المجموعة (كما تم مناقشته لاحقًا في قسم تخزين Amazon S3)، يجب أن تشمل سياسة الثقة أيضًا pods.eks.amazonaws.com كطرف موثوق. يستخدم الوصول عبر CLI من خلال Identity Center مجموعة أذونات منفصلة مع سياساتها الخاصة (انظر قسم “وصول الحساب AWS عبر Identity Center”)، لذا يمكن تحديد أذونات CLI بشكل مستقل.

تعرف أكثر: كيفية استخدام أدوار تنفيذ الذكاء الاصطناعي في SageMaker

وصول إلى حساب AWS عبر Identity Center

بالإضافة إلى SageMaker Studio، يحتاج الفرق غالبًا إلى الوصول المباشر إلى حساب AWS للقيام بعمليات CLI مثل تنفيذ أوامر kubectl، وكتابة برامج العملات، أو استخدام الموارد بشكل برمجي. توفر مجموعات التصاريح في Identity Center هذه القدرة.

للمجموعة الإداري，قم بتعيين مجموعة صلاحيات تحتوي على وصول إداري وفقًا لسياسات شركتك، وامنح الحسابات اللازمة للإدارة المجموعات والعمليات الإدارية.

بالنسبة لـفريق A وفريق B，قم بإنشاء مجموعات التصاريح مع سياسات مدمجة أو مُدارة تمنح الصلاحيات المطلوبة للعمليات العملية باستخدام CLI مباشرة. يتضمن مجموع أذونات الفريق النموذجي صلاحيات لـeks:AccessKubernetesApi (لعرض موارد Kubernetes من واجهة AWS Console)، بالإضافة إلى وصول S3 المحدد لمحتوى الفريق، ووصول قراءة CloudWatch للمراقبة. تُعرَّف هذه السياسات بشكل مستقل عن دور التنفيذ في Studio، بحيث يمكن للمديرين تعديل أذونات CLI لتتناسب مع العمليات المحددة التي يقوم بها الفريق من خط الأوامر.

يحصل المستخدمون على معرفات مؤقتة من خلال واجهة سطر الأوامر لـ AWS (AWS CLI) باستخدام دالة aws sso login، ويمكنهم استخدامها لإعداد kubectl للتفاعل المباشر مع مجموعة EKS.

تُظهر الصورة التالية مجموعات الصلاحيات لكل فريق في AWS IAM Identity Center، وتوفر وصول حساب AWS محدود لعمليات CLI مثل تشغيل kubectl وaws sso login ضد كتل EKS.

الشكل 4: مجموعات الصلاحيات لكل فريق في AWS IAM Identity Center للعمليات العملية باستخدام CLI

تعلم المزيد: إدارة حسابات AWS باستخدام مجموعات الصلاحيات

تهيئة أداة AWS CLI

يقوم أعضاء الفريق بتكوين أداة AWS CLI لتوثيق الحساب عبر Identity Center عن طريق تشغيل aws configure sso. هذا يخلق 프로필ات في ~/.aws/config تشير إلى جلسة Identity Center والمجموعة المخولة المناسبة. يستخدم كل عضو فريق 프로필 الخاص بالفريق عند التفاعل مع الكلوك من سطر الأوامر، مما يحافظ على حدود التفويض سواء كان الوصول قادم من Studio أو من الطرفية المحلية.

تحدد الإعدادات الناتجة كتلة مشتركة sso-session لبوابة Identity Center، بالإضافة إلى ملف مُسمى واحد لكل فريق، حيث يشير كل منهما إلى مجموعة الصلاحيات الخاصة بذلك الفريق. ثم يقوم أعضاء الفريق بتنفيذ aws sso login --profile <team> للحصول على بطاقات اعتماد مؤقتة تخص مجموعة الصلاحيات الخاصة بهم:

[sso-session my-sso]
sso_start_url = https://d-xxxxxxxxxx.awsapps.com/start
sso_region = us-west-2
sso_registration_scopes = sso:account:access

[default]
sso_session = my-sso
sso_account_id = 123456789012
sso_role_name = OpsAdmin
region = us-west-2

[profile team-a]
sso_session = my-sso
sso_account_id = 123456789012
sso_role_name = TeamA-permission-set
region = us-west-2

[profile team-b]
sso_session = my-sso
sso_account_id = 123456789012
sso_role_name = TeamB-permission-set
region = us-west-2

تعلم المزيد: تكوين التحقق من هوية IAM Identity Center باستخدام AWS CLI

دوائر الذكاء الاصطناعي في ساجيمير

توفر مجالات SageMaker AI حدودًا لبيئة العمل لكل فريق، وتقدم تجربة مستخدم مخصصة، وأدوار تنفيذ مُهيأة مسبقًا، واندماجًا داخليًا مع التحقق من الهوية في Identity Center.

لماذا عوالم SageMaker للذكاء الاصطناعي

استخدام مجال واحد من SageMaker AI لكل فريق هو نمط مُعتاد جدًا لتنظيم البيئات المتعددة الأفرق. يوفر هذا النهج عدة مزايا:

• نمط توزيع الفرق المتعددة – قامت AWS بتوثيق هذا النهج بشكل مفصل لتفريق فروع الأعمال أو الفرق ذات العديد من المجالات، مما يجعله إعدادًا مثبتًا ومدعومًا.
• تحقق هوية Identity Center الأصلية – يمكن تكوين كل مجال باستخدام تحقق هوية Identity Center، مما يعني أن المستخدمين يقومون بالتسجيل مرة واحدة من خلال مزود الهوية المؤسسية الخاص بهم، ويصلون مباشرة إلى بيئة Studio لفريقهم.
• تكوين الفريق المدمج – توفر المجالات الجغرافية بالفعل آليات لتحديد التكوينات لل مستخدمين والفرق دون الحاجة إلى كيانات مخصصة إضافية. على سبيل المثال، يمكن تحديد إعدادات مثل دور تنفيذ الفريق على مستوى المجال الجغرافي، وإعادة تعيينها على مستوى ملف المستخدم للحصول على أقصى قدر من المرونة.
• تخصيص التوجيه – مع إعدادات النطاق، يمكن للمديرين إخفاء عناصر التوجيه التي لا تتعلق بعملية العمل الخاصة بالفريق، مما يعرض واجهة مركزة تتماشى مع حالات استخدام HyperPod.

تعلم المزيد: كيانات حالة مجالات الذكاء الاصطناعي في SageMaker · نظرة عامة على المجالات المتعددة

تهيئة أسماء النطاقات لكل فريق

إنشئ مجالًا واحدًا لـ SageMaker AI لكل فريق باستخدام التحقق من الهوية في Identity Center. في مثالنا، ننشئ TeamA-domain وTeamB-domain. يتم تكوين كل مجال على النحو التالي:

1. دور التنفيذ الافتراضي – قم بضبط دور التنفيذ الافتراضي للنطاق إلى دور IAM الخاص بالفريق الذي تم إنشاؤه في خطوة التفويض. جميع الإجراءات التي يتم تنفيذها من خلال Studio تنتقل بها الصلاحيات المناسبة كنتيجة لذلك.
2. تخصيص المجموعة في مركز الهوية – أضف المجموعة المناسبة في مركز الهوية (على سبيل المثال، مجموعة TeamA) إلى النطاق. هذا سيؤدي إلى تفعيل تطبيق SageMaker Studio لجميع أعضاء تلك المجموعة، مما يمنحهم إمكانية الوصول إلى واجهة Studio.
3. تحقق من تخصيص التطبيق – بعد تهيئة الوصول الجماعي، قم بمراجعة تخصيص التطبيق في Identity Center للتأكد من أن المجموعات الصحيحة تم تطابقها مع النطاقات الصحيحة.
4. تخصيص التحكم في التنقل – ضبط إعدادات التنقل الافتراضية لكل مجال لتعرض فقط الميزات ذات الصلة. على سبيل المثال، يمكنك إخفاء العناصر غير المتعلقة بعمليات HyperPod، مما يوفر تجربة أكثر سلاسة. تركيز على HyperPod تجربة المستخدم التي تقلل من العبء المعرفي لأعضاء الفريق الذين يحتاجون فقط إلى العمل مع موارد HyperPod.

تُظهر الصورة التالية لواجهة SageMaker AI، حيث يوجد كل فريق في مجال منفصل (TeamA-domain وTeamB-domain)، ويوفر كل منهما حدًا مستقلًا للمساحة العمل.

الشكل 5: فريق واحد لكل مجال في SageMaker في لوحة SageMaker

ثم تُظهر الصورة التالية تفاصيل TeamA-domain， بما في ذلك المجموعات المخصصة في Identity Center.

الشكل 6: تكوين فريق A-domain مع مجموعات Identity Center المخصصة له

تكوين مجموعة HyperPod EKS

تُستخدم مجموعة HyperPod EKS لإدارة الأعمال. يتم تحقيق النظام المتعدد المشغلين على مستوى المجموعة من خلال فئات Kubernetes للحماية والإدراجات الخاصة بوصول EKS للتفويض.

عزل الفضاء

قم بإنشاء مساحة نطاق مخصصة لـ Kubernetes لكل فريق، على سبيل المثال hyperpod-ns-team-a و hyperpod-ns-team-b. توفر المساحات النطاقية حدًا منطقيًا داخل المجمع، مما تعزز عزل أعمال كل فريق (الفضاءات، وظائف التدريب، نقاط نهاية الاستدلال) عن بعضها البعض.

ملحوظة: الفضاءات الاسمية هي حد فصل، وليست حد فصل أمني صارم. يهدف هذا التصميم إلى فرق متعددة داخل منظمة واحدة: فرق تشارك في مجموعة تحت نطاق إداري مشترك وقاعدة أساسية من الثقة المتبادلة. لم يتم تصميمه للفصل لعملاء متعددين بين مستأجرين غير موثوق بهم معًا.

المجالات الاسمية، نظام RBAC، والحصص تمنع التدخلات العرضية (كما لو أن الفرق تغيير الموارد للفريق الآخر أو تتجاوز مخصصاتها الحاسوبية)، لكنها لا تكون حاجزًا ضد مستخدم خبيث عازم: الفقاعات المرتبطة بالمجالات الاسمية تشترك في نفس العقد والنواة، أما الموارد المشتقة من المجموعة (العقد، PersistentVolumes，CRDs، بعض مكونات التشغيل) فهي توجد خارج أي مجال اسمي.

للمستأجرين غير الموثوق بهم أو للحاجة إلى عزل تنظيمي صارم، يجب استخدام حدود أقوى مثل مجموعات منفصلة أو حسابات منفصلة، مجموعات عقدات عميلة مخصصة، وتطبيق عزل محلي للتشغيل. بالنسبة لسيناريو الأفراد المتعددين هنا، فإن عزل العناوين الافتراضية المدمجة مع نظام RBAC، وحدود توزيع المهام، وضوابط الهوية POSIX الموصوفة لاحقًا، يخلق توازنًا مناسبًا بين الفصل والبساطة التشغيلية.

يمكن إنشاء الفضاءات الاسمية يدويًا باستخدام kubectl create namespace أو يتم توفيرها تلقائيًا من خلال نظام حوكمة مهام HyperPod، الذي يدير الفضاءات كجزء من تكوين الحصص وترتيب الأعمال.

تُظهر الصورة التالية مجموعات الأسماء (التي تُدار بواسطة نظام إدارة مهام HyperPod)، حيث يوجد اسم نطاق واحد منفصل لكل فريق (hyperpod-ns-team-a و hyperpod-ns-team-b) لتوفير عزل الأعمال.

الشكل 7: مساحة نطاق Kubernetes مخصصة لكل فريق لتفريد العمليات.

تعلم المزيد: مجالات Kubernetes

عزل الشبكة

لا تقييد الفضاءات الاسمية حركة الشبكة. بشكل افتراضي، شبكات Kubernetes منظمة بشكل مسطح: يمكن لكل وحدة عمل (pod) الوصول إلى أي وحدة عمل أخرى عبر جميع الفضاءات. ونتيجة لذلك، يمكن لوحدة عمل في hyperpod-ns-team-a فتح اتصال مع وحدة عمل في hyperpod-ns-team-b ما لم تضيف التحكمات اللازمة. لتمديد إمكانية الوصول بين الوحدات العمل حسب حدود الفرق، استخدم موارد Kubernetes NetworkPolicy.

النمط الموصى به هو default-deny لكل اسم مجال: ابدأ بمنع كل دخول (واختياريًا خروج)، ثم سمح صراحةً بالحركة المرورية التي يحتاجها كل فريق، عادةً الاتصالات داخل الاسم المجال بالإضافة إلى الخروجات المطلوبة مثل DNS ونقاط التوصيل للتخزين وواجهات برمجة التطبيقات الخاصة بـ AWS. المثال التالي يمنع كل دخول في اسم مجال الفريق، ثم يسمح بالحركة المرورية فقط من خلال الوحدات داخل نفس الاسم المجال:

# 1. Default-deny all ingress in the team's namespace.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: hyperpod-ns-team-a
spec:
  podSelector: {}  # applies to all pods in the namespace
  policyTypes:
  - Ingress
---
# 2. Allow ingress only from pods within the same namespace.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: hyperpod-ns-team-a
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector: {}  # any pod in this namespace

يعتمد تطبيق NetworkPolicy على واجهة شبكة الحاوية (CNI) التي تدعم ذلك. على EKS، يمكنك تفعيل دعم سياسة الشبكة في واجهة شبكة Amazon Virtual Private Cloud (Amazon VPC).

كما في حالة العناوين الفئوية، NetworkPolicies الحد من عرض عرضي إمكانية الاتصال بين الفرق المختلفة وتقليل نطاقها، لكن هذه الأمور وحده لا تشكل حدود أمان تنافسية على العقد المشتركة. من أجل فصل أكثر قوة، يمكن النظر إلى مجموعات عقد مخصصة لكل فريق أو مجموعات منفصلة، كما تم ذكره سابقًا.

تعلم المزيد: سياسات الشبكة في كوبرنيتيست · سياسة الشبكة CNI لمنطقة VPC الخاصة بأمازون

إدخالات الوصول إلى EKS

تربط فئات الوصول إلى EKS أجهزة IAM بالصلاحيات RBAC في Kubernetes. لكل فريق، قم بإنشاء فئتين من الوصول:

• دخول الوصول إلى Studio – هو دور وظيفة تنفيذ مجال الذكاء الاصطناعي في SageMaker الخاص بالفريق. يُستخدم هذا الدخول عندما تكون الأفعال مصدرها واجهة GUI لـ SageMaker Studio.
• دخول الوصول إلى CLI – الرئيسي لـ IAM هو الدور المُخصص عبر SSO الذي تم إنشاؤه بواسطة Identity Center للحساب المجموعة الخاصة بالفريق (وفقًا للنمط) AWSReservedSSO_<permission-set-name>_<unique-id>). يتم استخدام هذا البند عندما يتفاعل المستخدمون مع المجموعة عبر kubectl.

تقع كلا القائمة ضمن مساحة النطاق الخاصة بالفريق، باستخدام سياسات Kubernetes المُدار أو المخصصة. على سبيل المثال، تمنح كلا قائمة الفريق أ صلاحيات فقط داخل hyperpod-ns-team-a. يمكن للقائمتين اتخاذ سياسات RBAC مختلفة إذا رغبت. على سبيل المثال، قد تحد من القائمة باستخدام CLI الوصول إلى كتابة بعض أنواع الموارد، بينما تسمح القائمة باستخدام Studio بالوصول الكامل.

مع هذا الإطار التحديد، سواء كان الوصول يأتي من Studio أو من CLI، يمكن للمستخدمين التفاعل فقط مع الموارد ضمن مساحتهم الخاصة. وإجراء عمليات قائمة بأو تعديل الموارد في مساحة فريق آخر يؤدي إلى خطأ Forbidden في Kubernetes.

للحالات المتقدمة، يمكنك استخدام مجموعات Kubernetes في بيانات الوصول لتعيين المستخدمين إلى أدوار المجموعة المخصصة أو أدوار توفر تصاريح دقيقة تتجاوز السياسات الإدارية القياسية.

الصورة التالية تُظهر دخول الوصول إلى EKS لدور الفريق ب، محدودًا إلى مساحة الاسم نفسية hyperpod-ns-team-b، بحيث تطبق الصلاحيات فقط داخل مساحة اسم الفريق ب.

الشكل 8: مدخل الوصول إلى EKS محدود بعنوان النطاق الخاص بفريق B

تعرف أكثر: منح مستخدمي IAM حق الوصول إلى Kubernetes باستخدام مفاتيح الوصول لـ EKS

حوكمة مهام HyperPod

عند تفعيل إدارة المهام على المجموعة، يوفر ذلك طبقة إضافية لإدارة الموارد:

• حساب الحصص – حدد كمية القدرة على وحدات الرسومات الخاصة والوحدات المعلنة لكل فريق. هذا يمنع فريقًا واحدًا من الاستحواذ على الأجهزة المشتركة أثناء جلسات التدريب.
• الأولويات – تخصيص أولويات جدولة لكل فريق أو نوع من الأعمال، بحيث يمكن للأعمال الحرجة المتعلقة بالإنتاج أن تتجاوز أعمال التدريب التجريبي عندما تكون الموارد محدودة.
• الترتيب العادل – مع نظام إدارة المهام، عندما تتنافس فرق متعددة على الموارد، يتم تخصيصها وفقًا للسياسات المحددة بدلاً من نموذج الترتيب الحر.

قم بتنظيم إدارة المهام مع تحديد الحصص والأولويات المناسبة لكل اسم نطاق الفريق، مع تحقيق التوازن بين التخصيصات الدنيا المضمونة والقدرة على العمل في حالات الطلب العالي.

تُظهر الصورة التالية توزيعات حوسبة إدارة المهام لفرقتي العمل، حيث يتم تخصيص حصة من إمكانيات الحوسبة العنقودية لكل فريق على حدة.

الشكل 9: توزيع حصص الحوسبة لإدارة المهام حسب نطاق الأسماء للفريق

تعلم المزيد: حوكمة مهام SageMaker HyperPod

تخزين

التخزين هو مكون أساسي في بيئات الذكاء الاصطناعي وتعلم الآلات (AI/ML) المشتركة بين الفرق. تحتاج الفرق إلى أنظمة ملفات عالية الأداء لبيانات التدريب، ونتائج التحقق، وأعمال النماذج، مع الحفاظ على حدود الوصول المناسبة بين الفرق.

أنظمة الأفلام المتوافقة مع POSIX

بالنسبة للأعمال التي تتطلب نظام ملفات POSIX مشترك عالي الأداء (وهو شائع في التدريب الموزع حيث يقرأ العديد من العقد نفس مجموعة البيانات أو يكتب نقاط التحقق)، فكر في الخيارات التالية:

• Amazon FSx for Lustre – يوفر وصولًا إلى نظام ملفات متوازي ذو معدل استجابة عالي وزمن تأخير منخفض، وهو مثالي لأعمال التدريب على نطاق كبير التي تحتاج إلى قراءة مجموعات بيانات كبيرة بسرعة عالية.
• Amazon FSx for OpenZFS – يوفر نظام ملفات عام بأخلاقيات POSIX قوية، مع لقطات وتقريب. مناسب جيدًا للأعمال التي تحتاج إلى خصائص نظام الملفات التقليدية بالإضافة إلى الأداء العالي.
• نظام الملفات المرن من أمازون (Amazon EFS) – يوفر تخزين نظام الملفات الشبكية المرن (NFS) مع إدارة كاملة. كما يدعم نظام EFS نقاط الوصول، مما يسهل عزل الدиректорيات لكل فريق عن طريق تخصيص مواقع التوصيل المختلفة لمكتبات منفصلة مع معايرنة UIDs و GIDs.

تتبع تخطيط التخزين عادةً هذه الهيكلية:

• المجلدات المشتركة لكل فريق – لكل فريق يوجد مجلد مشترك (مثلاً /fsx/TeamA، /fsx/TeamB) لالبيانات والنماذج والعناصر التي يحتاج جميع أعضاء الفريق إلى الوصول إليها.
• محطات البيت الخاصة بكل مستخدم – لكل مستخدم يوجد محطة بيت شخصية (على سبيل المثال، /home/User1، /home/User2) للعمل الفردي والتجارب والدفاتر.

نموذج الأذونات POSIX في أنظمة الملفات هذه يعتمد على UIDs وGIDs والمجموعات الإضافية لتنفيذ حدود الوصول. يجب نقل هذه الهويات POSIX إلى سياق أمان pod عندما يقوم المستخدم بتشغيل HyperPod Space أو تقديم مهمة تدريب، حتى يتم احترام حقوق الملف والأذونات المُعدة لها. نوصي باستخدام خطوة القبول التعديلية في Kubernetes لاسترجاع معلومات الهوية POSIX من مستودع الهوية الخاص بك. عند تقديم عبء العمل، يقوم الويبهوك ببحث الهوية أثناء التشغيل، ويعدل سياق الأمان لـ Pod وفقًا لذلك.

# 1. Extract the caller's session identity from the admission request.
# On EKS, requests from IAM-assumed roles (including IAM Identity Center)
# surface the STS session name in userInfo.extra["sessionName"]. Its format
# depends on how the session is created (e.g., an SSO short name, an email,
# or a role-session-name); align your identity mapping with this value.
def extract_username(admission_request):
    extra = admission_request["userInfo"]["extra"]
    ...
    return extra["sessionName"][0]

# 2. Look up the POSIX identity from a mapping table (e.g. DynamoDB).
def lookup_posix_identity(username):
    item = posix_table.get_item(Key={"username": username})["Item"]
    ...
    return {
        "uid": int(item["uid"]),
        "gid": int(item["gid"]),
        "supplementalGroups": [int(g) for g in item["supplementalGroups"]],
    }

# 3. Patch the Pod security context with the resolved POSIX identity.
def build_security_context_patch(pod, posix):
    ...
    return [{
        "op": "add",
        "path": "/spec/securityContext",
        "value": {
            "runAsUser": posix["uid"],
            "runAsGroup": posix["gid"],
            "fsGroup": posix["gid"],
            "supplementalGroups": posix["supplementalGroups"],
        },
    }]

تعلم المزيد: FSx for Lustre · FSx for OpenZFS · Amazon EFS

تخزين أمازون S3

بالنسبة لتخزين الكائنات، يتم التحكم في الوصول إلى صناديق S3 من خلال دور تنفيذ IAM للفريق. يمكنك إنشاء صناديق لكل فريق أو استخدام صندوق مشترك مع بادئات خاصة بكل فريق، مع الاعتماد على سياسات IAM لتحقيق العزل. يحتاج العمال داخل الخليط إلى حسابات خدمة مناسبة مُعدة بأدوار IAM للحسابات الخدمة أو هوية العمال لإتمام التحقق من هويتهم مع S3. لأغراض البساطة، يمكنك ربط نفس دور التنفيذ المُضبط على مجال SageMaker AI بحساب خدمة Kubernetes داخل مساحة الفريق، مما يوفر وصولًا متسقًا إلى S3 من خلال أعمال Studio والعمليات في المجمع.

تعلم المزيد: أدوار IAM للحسابات الخدمية (IRSA) · هوية EKS Pod

HyperPod Spaces

توفر HyperPod Spaces بيئات تطوير تفاعلية (IDEs) تعمل مباشرة على عقد العمال. في كومحور مشترك، يجب أن يتم تخصيص Spaces بشكل صحيح ضمن مساحة الأسماء لكل فريق، ويجب تهيئةها باستخدام قوالب الموارد المناسبة.

قوالب الفضاء

إنشئ قوالب الفضاءات المخصصة بمجال الاسم لكل فريق. تحدد هذه القوالب إعدادات الموارد (أنواع العمليات، حجم التخزين، متغيرات البيئة) المتاحة لأعضاء الفريق عند إنشاء الفضاءات. من خلال تخصيص القوالب لمجال الاسم، تضمن أن كل فريق يمكنه إطلاق الفضاءات داخل حدوده المحددة.

عند تشغيل نظام حوكمة مهام HyperPod، يجب أن تتضمن القوالب العلامات الافتراضية التي يتطلبها نظام الحوكمة (مثل أسماء الفرق والعلامات الأولوية). يقوم مسؤول المجموعة بتكوين هذه العلامات مسبقًا، بحيث لا يحتاج أعضاء الفريق إلى تحديدها يدويًا عند بدء تشغيل Spaces.

يوضح المثال التالي قالب Space لـ JupyterLab مخصص للفريق A. الأجزاء المتعلقة بالفريق هي metadata.namespace، وعلامة طابور إدارة المهام تحت baseLabels، وdefaultVolumes التي تُثبّت نظام الملفات المشترك للفريق ومجلد المنزل للمستخدم:

apiVersion: workspace.jupyter.org/v1alpha1
kind: WorkspaceTemplate
metadata:
  name: jl-smd-custom
  namespace: hyperpod-ns-team-a  # scopes the template to Team A's namespace
spec:
  displayName: "JupyterLab (team-a)"
  description: "SageMaker Distribution"
  appType: jupyterlab
  baseLabels:
  - key: kueue.x-k8s.io/queue-name  # Task Governance (Kueue) local queue for Team A
    value: hyperpod-ns-team-a-localqueue
  ...
  # container command, default CPU/memory resources, security context, access type, etc.
  ...
  defaultVolumes:
  - name: home-dir  # per-user home directory
    mountPath: /home
    persistentVolumeClaimName: fsx-openzfs-claim
  - name: shared-data  # Team A's shared directory
    mountPath: /fsx
    persistentVolumeClaimName: fsx-lustre-claim
  ...
  # primary (EBS) storage defaults and limits
  ...

ادعاءات الحاوية المستمرة

إنشاء مطالبات الوحدة الاحتفاظية المستمرة المناسبة في كل نطاق الفريق، مع الإشارة إلى نظام الملفات المشترك. تُثبّت هذه المطالبات الوحدة الاحتفاظية الملفات المشتركة للفريق ومجلد المنزل الخاص بالمستخدم داخل الفضاء، مما يوفر إمكانية الوصول إلى بيانات التدريب والنقاط التفتيش وبيئات العمل الشخصية.

فضاءات خاصة بالمالك فقط ويمكن المشاركة فيها

فكر في متطلبات منظمتك بخصوص مشاركة الفضاء:

• مساحات للملاك فقط – يمكن الوصول إلى كل مساحة فقط من قبل الشخص الذي أنشأها. هذه هي الإعدادات الافتراضية، وهي مناسبة عندما تعمل الفرق على مشاريع حساسة أو مستقلة.
• الفضاءات المشتركة – يمكن لأعضاء الفريق المتعددين الوصول إلى نفس الفضاء، وهو مفيد للبرمجة التكاملية، أو تصحيح الأخطاء المشترك، أو بيئات التطوير المشتركة. عند تفعيل الفضاءات المشتركة، تأكد من إعداد صلاحيات POSIX والمجموعات الإضافية بحيث يُسمح بالوصول المناسب إلى الملفات التي تم إنشاؤها داخل الفضاء.

تعرف أكثر: بيئات التطوير التفاعلية على مجموعات EKS HyperPod من Amazon SageMaker

تجربة الاستوديو

على الرغم من أن الفرق يمكنها التفاعل مع العنصر المجمع بالكامل من خلال CLI باستخدام kubectl، فإن SageMaker Studio يوفر نقطة دخول بيانية للعنصر المجمع للأشخاص الذين يفضلون عملية تشغيل مدارة وموجهة بالواجهة الرسومية. في هذا التصميم، يحصل كل فريق على وصول إلى Studio من خلال مجال SageMaker AI الخاص به (كما هو موضح سابقًا)، ويتم تسجيل الدخول باستخدام نفس مفاتيح الهوية في Identity Center، ويتم التشغيل ضمن حدود مساحة الاسم المستعار الخاصة بالفريق.

تُظهر الصورة التالية بوابة الوصول في IAM Identity Center، التي يصل إليها المستخدمون بعد تسجيل الدخول باستخدام بطاقات هويتهم الشركة، مما يوفر وصولًا من نوع single sign-on للتطبيقات المخصصة لـ SageMaker Studio والتطبيقات لـ Amazon Managed Grafana.

الشكل 10: بوابة الوصول في IAM Identity Center مع تسجيل الدخول الواحد للتطبيقات المخصصة

من واجهة التشغيل في الاستوديو، يمكن لأعضاء الفريق:

• إدارة فضاءات HyperPod – يمكن تطوير بيئات التطوير التفاعلية من قوالب فضاءات محددة في النطاق الاسمي التي قام المسؤول بتكوينها، دون الحاجة إلى كتابة وثائق Kubernetes أو تحديد علامات إدارة المهام يدويًا. كما يمكن أعضاء الفريق بدء تشغيل فضاءاتهم وتوقفها والاتصال بها، مع فتح محرر الاكتشاف المتعدد المرتبط بها مباشرة من المتصفح.
• إدارة أعمال Ray – إنشاء ومراقبة مجموعات Ray، توصيل منطقة عمل JupyterLab أو Code Editor بمجموعة، تقديم مهام موزعة، فتح لوحة تحكم Ray ولوحات تحكم Amazon Managed Grafana للملاحظة، كل ذلك دون كتابة مانيفستات Kubernetes أو تشغيل أوامر kubectl.

نظرًا لأن Studio يعمل من خلال دور فريق التشغيل في النطاق، والدخول المقابل لـ EKS، فإن جميع الإجراءات تُحصر ضمن نطاق اسم النطاق الخاص بالفريق. يمكن للمستخدم الذي يشغل مساحة أو مجموعة Ray من Studio أن يقوم بإنشائها داخل حدود فريقه الخاص، وذلك وفقًا لنموذج العزل المطبق للوصول عبر CLI.

تُظهر الصورة التالية كيفية إنشاء مساحة HyperPod من خلال واجهة SageMaker Studio، حيث يختار أحد أعضاء الفريق قالب المساحة المخصص للعنوان، دون الحاجة إلى كتابة ملفات Kubernetes أو تحديد تسميات إدارة المهام يدويًا.

الشكل 11: إنشاء مساحة HyperPod من قالب محدود باسم الفضاء في SageMaker Studio

تعلم المزيد: بيئات التطوير التفاعلية على مجموعات EKS لـ Amazon SageMaker HyperPod · إطلاق ميزات جديدة من Ray على SageMaker HyperPod

مشغل تدريب HyperPod

يُمكّن مشغل تدريب HyperPod الفرق من تقديم أعمال التدريب الموزعة كموارد مخصصة لـ Kubernetes (مثل HyperPodPyTorchJob). في بنية العديد من الأطراف، تكون أعمال التدريب محصورة ضمن نطاق الناموسيات، مما يعني أنها توريث حدود العزل الخاصة بالفريق تلقائيًا.

يمكن للفرق تقديم وظائف التدريب من خلال الأوامر اليدوية باستخدام kubectl apply مع ملف الوظيفة المناسب. تُنفَّذ الوظيفة في الفضاء الخاص بالفريق، وتستخدم حدود الحساب الإلكتروني للفريق (إذا كان نظام إدارة المهام مفعّلًا)، ولها إمكانية الوصول إلى أجزاء التخزين الخاصة بالفريق.

عند تشغيل إدارة المهام، تخضع مهام التدريب للحصص المخصصة للفريق وإعدادات الأولوية الخاصة بهم. إذا استهلك الفريق الحصص المضمونة لهم، قد يتم ترتيب المهام حتى تتوفر الموارد أو حتى يتم تأجيل المهام ذات الأولوية الأقل.

العنصران اللذان يربطان المهمة بالفريق هما metadata.namespace (الذي يحدد نطاق المهمة ضمن حدود العزل للفريق) وملصقات إدارة المهام. تم بناء إدارة المهام على منصة Kueue، لذا يتم توجيه المهمة إلى الصفقة المحلية للفريق عبر kueue.x-k8s.io/queue-name. ويتم تعيين أولوية الترتيب لها من خلال kueue.x-k8s.io/priority-class، حيث يكون قيمته اسمًا لـWorkloadPriorityClass المحدد في الكلاستر:

apiVersion: sagemaker.amazonaws.com/v1
kind: HyperPodPyTorchJob
metadata:
  name: team-a-training-job
  namespace: hyperpod-ns-team-a  # scopes the job to Team A's namespace
  labels:
    kueue.x-k8s.io/queue-name: hyperpod-ns-team-a-localqueue  # Task Governance (Kueue) local queue
    kueue.x-k8s.io/priority-class: training-priority  # name of a WorkloadPriorityClass
spec:
  ...
  # replicaSpecs, container image, command, resources, volumes, etc.
  ...

تعلم المزيد: استخدام مشغل التدريب HyperPod

مشغل الاستدلال HyperPod

يسمح عامل الاستدلال HyperPod للفرق بتركيب النماذج كنقاط نهاية استدلال مباشرة على المجمع. ومثل أعمال التدريب، تكون نقاط النهاية الاستدلالية مشمولة في مساحة الاسم العام وخاضعة لسياسات RBAC للفريق وحدود إدارة المهام.

يمكن للفرق نشر النماذج من خلال لوحة التحكم باستخدام الموارد المخصصة لنقاط النهاية للاستدلال داخل مساحتهم العنوانية. تكون نقاط النهاية معزولة حسب كل مساحة عنوانية، مما يعني أن الفريق أ لا يمكنه الوصول إلى نقاط نهاية الاستدلال الخاصة بالفريق بي أو التدخل فيها.

لأعمال الأداء الإدراكي في الإنتاج التي تتطلب توافر عالي، يُنصح بتعيين أولوية تنظيم أعلى لنقاط النهاية للإدراك مقارنةً بأعمال التدريب، حتى لا يتعرض خدمة النموذج للتوقف بسبب أعمال الأداء الإدراكي للتدريب الجماعي.

كما في حالات التدريب، يوضع نقطة الاستنتاج في metadata.namespace للفريق ويحمل علامات إدارة المهام. هنا، يشير kueue.x-k8s.io/priority-class إلى WorkloadPriorityClass ذو الأولوية الأعلى، بحيث يمكن لخدمة النموذج أن تمنع التدريب الدفعة عندما تكون موارد الفريق محدودة.

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: team-a-inference-endpoint
  namespace: hyperpod-ns-team-a  # scopes the endpoint to Team A's namespace
  labels:
    kueue.x-k8s.io/queue-name: hyperpod-ns-team-a-localqueue  # Task Governance (Kueue) local queue
    kueue.x-k8s.io/priority-class: inference-priority  # higher-priority WorkloadPriorityClass
spec:
  ...
  # model source, instance type, replica count, autoscaling, etc.
  ...

تعلم المزيد: نشر النماذج على Amazon SageMaker HyperPod

HyperPod مراقبة الأداء

إن القدرة على رؤية حالة العقد، وأداء الحمل العمل، واستخدام الموارد ضرورية لجميع الفرق. يوفر HyperPod Observability قدرات مراقبة ومعرض بيانات مدمجة من خلال Amazon Managed Grafana.

تكوين وصول الفريق إلى Grafana

تحتاج الفرق إلى الوصول إلى لوحة التحكم الخاصة بالملاحظة للمراقبة على أعمالها، وازالة المشاكل المتعلقة بأداء النظام، وفهم استهلاك الموارد. ومع ذلك، في بيئة متعددة الأطراف، يجب أن يكون هذا الوصول نمطًا خاصًا لا يمكن قراءته إلا.

1. تكوين المصادقة في Identity Center لـ Amazon Managed Grafana – على لوحة تحكم Amazon Managed Grafana، انتقل إلى خيار Authentication وافتح AWS IAM Identity Center. يمكن للمستخدمين بعد ذلك تسجيل الدخول إلى Grafana باستخدام نفس بيانات الاعتماد المؤسسية التي يستخدمونها لـ SageMaker Studio.
2. تعيين مجموعات الفريق كمشاهدين – قم بربط مجموعات Identity Center (TeamA, TeamB) بشخصية المشاهد في Grafana. هذا يمنح أعضاء الفريق حق الاطلاع فقط على لوحات القيادة والمؤشرات، دون قدرة على تعديل لوحات القيادة أو مصادر البيانات.
3. وصول الإدارة – قم بتعيين المجموعة Admin إلى دور مدير أو محرر Grafana، حتى يتمكنوا من إنشاء وتعديل لوحات القيادة، وتكوين التنبيهات، وإدارة مصادر البيانات.
4. لوحات العرض الخاصة بالفريق – يُفضل إنشاء لوحات عرض مخصصة تُحسب البيانات حسب النطاق، بحيث يرى كل فريق مقاييس العمل الخاصة به فقط. يدعم Amazon Managed Grafana Grafana Teams (مفهوم RBAC أصيل من Grafana، مختلف عن الفرق التنظيمية في هذا النظام)، والذي يمكن تطبيقه من مجموعات Identity Center لتقييد رؤية لوحات العرض وتوفير طبقة إضافية من عزل البيانات.

تُظهر الصورة التالية توزيع أدوار Grafana في Amazon Managed Grafana. مجموعات الفريق (TeamA, TeamB) مُنحت دور المشاهد لإمكانية قراءة العدادات والمقاييس فقط، بينما تم تخصيص مجموعة الإدارة لدور الإدارة، مما يمنحها القدرة على إنشاء وتعديل العدادات، وتكوين تنبيهات، وإدارة مصادر البيانات.

الشكل 12: توزيع أدوار Grafana الممنوحة للفرق للحصول على وصول مشاهدة فقط

تعرف أكثر: مراقبة Amazon SageMaker HyperPod المجمع بواسطة Amazon EKS

تخصيص التكاليف ودفع الفوائد

في بيئة متعددة المشغلين حيث تشارك الفرق في البنية التحتية باهظة الثمن للواجهات الرسومية، فإن معرفة من الذي يستخدم ما، أمر ضروري للتحقق من المسؤولية والميزانية والدفع. يلبي Kubecost هذه الحاجة من خلال تحليل الإنفاق داخل الكلوستر عبر مفاهيم Kubernetes الأصلية (المجالات، العلامات، النشر، والخدمات) وتمكينها بمفاهيم تنظيمية مثل الفرق والمشاريع أو البيئات.

لأن هذا التصميم يقوم بالفعل بعزل كل فريق في مساحة نطاق مخصصة (hyperpod-ns-team-a، hyperpod-ns-team-b)، فإن توزيع تكاليف مستوى النطاق يتم توافقها مباشرة مع حدود الأفريق. وهذا يوفر لمديري المنصة رؤية واضحة لكل فريق بشأن استهلاك الرسومات العصبية، ووحدة المعالجة المركزية، والذاكرة، والتخزين، والشبكة دون أي تسميات أعباء إضافية. للحصول على تعليمات خطوة بخطوة حول نشر وتكوين Kubecost في مجموعة HyperPod، يرجى الرجوع إلى Kubecost على SageMaker HyperPod.

تفعيل إمكانية رؤية الفريق

بعد أن يقوم كوبيكونست بجمع البيانات، يتم تصنيف التكاليف حسب النطاق في لوحة تحكم التخصيص لعرض الإنفاق لكل فريق. وبما أن كل فريق يمتلك نطاقًا خاصًا، فإن ذلك يؤدي مباشرة إلى تفصيل التكاليف لكل فريق التي تشمل الحوسبة، والذاكرة، والتخزين، والشبكة. تمامًا كما في لوحات تحكم القابلية للملاحظة، يستفيد الأقسام من إمكانية رؤية بيانات تكاليفهم الخاصة:

• تحويل نتائج الرؤية إلى مساحة الأسماء للفريق الواحد – يدعم Kubecost التصفية والتقارير المحفوظة بناءً على مساحة الأسماء، بحيث يمكن لكل فريق مراجعة استهلاكه واتجاهاته الخاصة دون رؤية بيانات الفرق الأخرى.
• إعداد الميزانيات والإنذارات – قم بتكوين عتبات الميزانيات والإنذارات لكل منطقة نطاق، حتى يتم إبلاغ الفرق ومسؤولي المنصة عندما يقترب الإنفاق من الحدود المحددة، مما يدعم أهداف العدالة في استخدام الموارد المشتركة مع نظام حوكمة مهام HyperPod.
• دعم عمليات الشحن والعرض – يمكن أن تُستخدم تقارير التخصيص على مستوى النطاقات الاسمية لتزويد أفراد قسم الفوترة الداخليين ببيانات حول عمليات الشحن أو العرض (التقارير التي لا تتضمن فوترة الاستخدام)، مما يوفر للأفراد المسؤولين عن المالية والمنصة البيانات اللازمة لتخصيص تكاليف الشريحة الرسومية المشتركة بشكل عادل.

تُظهر الصورة التالية لواجهة تحليل تخصيصات كوبوكست، مرتبة حسب النطاق، والتي تُظهر التكلفة المتراكمة خلال الـ 7 أيام الأخيرة لكل نطاق فريق.

الشكل 13: لوحة تحكم بتوزيع تكاليف كوبوكست، مصنفة حسب النطاق لتحليل التكاليف لكل فريق

تعلم المزيد: Kubecost على SageMaker HyperPod · Kubecost

الخلاصة

قدمت هذه المقالة هيكلاً مرجعيًا لبناء بيئات متعددة الأطراف على Amazon SageMaker HyperPod مع EKS. من خلال دمج مركز هوية IAM في AWS لإجراء المصادقة، وأدوار IAM لكل فريق للتفويض على مستوى AWS، ومجالات SageMaker AI لتجربة عمل مخصصة، واسماء الفئات في Kubernetes لعزل الأعمال، وحوكمة المهام في HyperPod لتوزيع الموارد بشكل عادل، وتوزيع التكاليف على مستوى الاسماء الفئات لإمكانية رؤية الإنفاق لكل فريق، يمكن للفرق المتعددة مشاركة كومة واحدة من HyperPod EKS بكفاءة.

هذا نهج مرن وقابل للتجميع يجمع العديد من الوحدات الفرعية في حل متكامل. تتماشى البنية التحتية مع مجموعة متنوعة من الحالات الاستخدامية والهياكل التنظيمية. على سبيل المثال، يمكن للمنظمات توسيع هذا النموذج لتوصيل الفرق بعقد الشبكات HyperPod Slurm جنبًا إلى جنب مع EKS، مما يوفر تجربة متعددة الأجهزة موحدة عبر خدمات التنظيم المختلفة.

في حين أن هذه الطريقة تتطلب تجميع وتكوين عدة مكونات، فإن النتيجة هي درجة عالية من السيطرة والتخصيص يمكن تكييفها وفقًا لمتطلبات العزل الخاصة بالمنظمة وضمان الامتثال والاحتياجات التشغيلية لكل منها. ستظل الأنماط الأساسية (الاتحاد الهوية، عزل الباسون، RBAC، الحوكمة القائمة على الحصص، وتوزيع التكاليف) قابلة للتطبيق.

لبدء العمل، حاول بناء هذا الإعداد متعدد المستخدمين على مجمع Amazon SageMaker HyperPod EKS الخاص بك، واجعل الوحدات الأساسية تتناسب مع متطلبات العزل والإدارة والتخصيص التكلفة لمنظمتك.

حول المؤلفين