Amazon SageMaker HyperPod يمنح فرق تعلّم الآلة (ML) إمكانية الوصول إلى مجموعات كبيرة من الحوسبة المُسرّعة لتدريب النماذج وضبطها بدقة. عندما تتشارك عدة فرق في مجموعة واحدة، فإن الإعداد التقني يكون عادةً مباشراً. أما الجزء الصعب فهو الحوكمة. يجب عليك أن تقرر أي الفرق يمكنها استخدام المجموعة، وكمية السعة التي تحصل عليها كل فريق، وما يحدث عندما يتنافس حمل عمل فريق مع حمل عمل فريق آخر، ومن المسؤول عندما ينحرف الاستخدام عن السياسة. Amazon SageMaker Unified Studio يضيف اعتباراً آخر: يمكنك ربط مجموعة SageMaker HyperPod بمشروع بحيث يتمكن أعضاء الفريق من إطلاق أحمال العمل من مساحة عمل مشروعهم. هذه الراحة قيّمة، ولكن بعد أن تحصل فرق متعددة على رؤية مشتركة لنفس المجموعة، تصبح الضوابط التي تحكم من يستطيع فعل ما أكثر أهمية. في هذا المقال، نوضح كيفية إدارة SageMaker HyperPod من خلال SageMaker Unified Studio مع الحفاظ على ضوابط الحوكمة الأساسية. نتناول طبقات التحكم الأربع: المؤسسة والمشروع والمجموعة وحمل العمل. كما نشرح كيفية تصميم سياسات الهوية والسعة والرصد عبرها. وبحلول النهاية، سيكون لديك نموذج قابل للتكرار لتقديم موارد الحوسبة المعتمدة من SageMaker HyperPod لفرق تعلّم الآلة في سياق مشاريعهم، مع إبقاء عمليات المجموعة مع فريق البنية التحتية.
Amazon SageMaker HyperPod هي إحدى قدرات Amazon SageMaker AI. Amazon SageMaker Unified Studio هو بيئة تطوير البيانات والذكاء الاصطناعي حيث تبني الفرق باستخدام بياناتها وأدواتها. مع SageMaker Unified Studio، يمكنك ربط مشروع بمجموعة SageMaker HyperPod موجودة. يمكن بعدها للأعضاء إطلاق أحمال عمل تعلّم الآلة، ومراجعة معلومات المجموعة والمهام، وفتح سير عمل JupyterLab. وتواصل إدارة المجموعات من خلال واجهات وواجهات برمجة التطبيقات (APIs) الخاصة بـ Amazon SageMaker AI.
يمنح هذا الفصل فرق البنية التحتية نموذج تشغيل مفيداً. يمكنك إدارة بنية المجموعة التحتية من خلال عمليات تشغيل السحابة الراسخة. وفي الوقت نفسه، يمكنك تقديم موارد الحوسبة المعتمدة لفرق تعلّم الآلة في سياق مشاريعها. في هذا المقال، نصف كيف يمكنك تصميم حدود البنية التحتية، وحوكمة الوصول، وتوزيع السعة المشتركة، وتشغيل SageMaker HyperPod بشكل متسق من خلال SageMaker Unified Studio.
فهم الحدود الإدارية
البيئة المُحكَمة بشكل جيد تفصل بين الإدارة التنظيمية والوصول إلى المشاريع وعمليات المجموعة. تجيب كل طبقة عن سؤال مختلف وتستخدم ضابطاً مختلفاً. يلخّص الجدول التالي كل حد وضوابطه الأساسية وغرضه الإداري.
| الحد | الضوابط الأساسية | الغرض الإداري |
| المؤسسة | نطاقات SageMaker Unified Studio، ووحدات النطاق، والحسابات المرتبطة، وملفات تعريف المشاريع، وسياسات التخويل | تحدد من يمكنه إنشاء المشاريع، وأي الحسابات والمناطق يمكن للمشاريع استخدامها، وأي الأدوات متاحة |
| المشروع | عضوية المشروع، وأدوار المشروع، واتصالات SageMaker HyperPod | تحدد سياق التعاون وموارد AWS التي يمكن لأعضاء المشروع الوصول إليها |
| المجموعة | أدوار مسؤول مجموعة SageMaker HyperPod، وإدخالات وصول Amazon EKS، والتحكم بالوصول القائم على الأدوار (RBAC)، وEKS Pod Identity، أو ضوابط Slurm | تحكم في تكوين المجموعة، والوصول إلى المجدول، ومساحات الأسماء، والمهام، وعمليات البنية التحتية |
| حمل العمل | تخصيصات الحوسبة، وفئات الأولوية، وسياسات الإقراض والاقتراض، وأذونات المهام | تتحكم في من يمكنه إرسال العمل وكيفية توزيع السعة المشتركة |
تعامل مع هذه الضوابط كطبقات. يضيف اتصال SageMaker HyperPod مجموعة معتمدة إلى مشروع. فهو لا يستبدل ضوابط AWS Identity and Access Management (IAM) الخاصة بالمجموعة، أو Amazon Elastic Kubernetes Service (Amazon EKS)، أو Slurm. راجع دور المشروع، ودور وصول الاتصال، وإدخالات وصول EKS وضوابط RBAC أو Slurm، وهوية حمل العمل، وسياسات البيانات و مفتاح AWS Key Management Service (AWS KMS) وسياسة الشبكة، وقيود عرض المهام، وسياسة المجدول معاً. أجعل المجموعة متاحة فقط بعد توافق تلك الضوابط.
تشكل هذه الضوابط أربع طبقات، موضحة في الشكل التالي.
الشكل 1: طبقات التحكم الأربع: المؤسسة، المشروع، العنقود، وحِمل العمل. تجيب كل طبقة عن سؤال مختلف وتستخدم آلية تحكم مختلفة، لذا راجع كل طبقة عند حدودها الخاصة.
تُعدّ مشاريع SageMaker Unified Studio حدودًا للتعاون، وليست حدودًا قوية لأمن بيئة التشغيل. حافظ على عنقود SageMaker HyperPod والمجدِّد وسعة المُسرِّعات الشحيحة تحت حساب سعة واحد مُعيَّن. يمكن أن يبقى المستخدمون ومجموعات البيانات المُعتمدون في الحساب نفسه أو في حسابات منفصلة للمستهلكين والبيانات. توثِّق AWS الدعم متعدد الحسابات لحوكمة مهام SageMaker HyperPod على عناقيد Amazon EKS. وعلى الرغم من إمكانية مشاركة حجوزات السعة عند الطلب (On-Demand Capacity Reservations) عبر الحسابات، فقم بمركزية ملكية عنقود SageMaker HyperPod وإدارة السعة في حساب السعة. استخدم الوصول المعتمد عبر الحسابات بدلاً من جعل كل حساب مستهلك مدير سعة مستقلاً.
- بالنسبة إلى Amazon EKS، استخدم مساحة أسماء (namespace) لكل مستأجر مع RBAC وحسابات خدمة لكل مستأجر وأدوار EKS Pod Identity، وسياسات شبكة رفض افتراضي (default-deny)، وأذونات تخزين وأذونات AWS KMS خاصة بكل مستأجر. أما بالنسبة إلى Slurm، فاستخدم محاسبة Slurm مع حسابات هرمية وارتباطات، وجودة الخدمة (QoS)، وسياسات الأولوية والحصة العادلة (fair-share)، والأقسام (partitions). استخدم أيضًا هوية نظام التشغيل وأذونات الملفات، وضوابط الشبكة، ومسارات بيانات خاصة بكل مستأجر.
- استخدم أدوار IAM وسياسات الموارد، بدلاً من الاعتماد على عضوية المشروع وحدها، للتحكم في الوصول إلى حاويات Amazon Simple Storage Service (Amazon S3)، ومفاتيح AWS KMS، والأسرار، وسجلات الحاويات، وخدمات البيانات الأخرى. استخدم سياسات المشروع ووحدة النطاق (domain-unit) للتعاون والتفويض.
- بالنسبة إلى مجموعات Amazon EKS، استخدم حوكمة المهام في SageMaker HyperPod، بما في ذلك الحصص وفئات الأولوية والإقراض والاقتراض والاستباق (preemption)، لمشاركة مكانة المُسرِّعات المركزية بإنصاف. أما بالنسبة إلى مجموعات Slurm، فاستخدم ضوابط الأقسام الأصلية وجودة الخدمة (QoS) والأولوية والحصة العادلة والاستباق. لا يوفر Slurm نموذج الإقراض والاقتراض ذاته. تحدد ضوابط الجدولة هذه وقت حصول حمل العمل المصرّح له على موارد الحوسبة. وهي لا تمنح الوصول إلى مساحات الأسماء أو البيانات.
لمعزلن أقوى داخل المجموعة، استخدم عقدًا أو مجموعات عقد مخصصة وضوابط قبول (admission controls) حيثما كان ذلك مناسبًا. استخدم مجموعة أو حسابًا منفصلاً عندما تفرض المتطلبات القانونية أو التنظيمية أو الأمنية عزلًا صارمًا للبنية التحتية. يمكن لوصول المستهلك عبر الحسابات (cross-account) الحفاظ على ملكية على مستوى الحساب دون تكرار مجموعة SageMaker HyperPod المركزية. داخل حساب السعة، استخدم ملفات تعريف المشروع (project profiles) و وحدات النطاق (domain units) مع سياسات ترخيص المشروع لتفويض إنشاء المشاريع وملكيتها.
يوضح الشكل التالي السعة المركزية مع ضوابط خاصة بكل مستأجر لحمل العمل والهوية والبيانات والشبكة والرؤية.
الشكل 2: سعة SageMaker HyperPod المركزية. تبقى المجموعة والمجدول في حساب سعة واحد. يتلقى كل مستأجر ضوابط لحمل العمل والهوية والبيانات والشبكة ورؤية المهام. وتستخدم متطلبات العزل الصارم بنية تحتية مخصصة.
يوضح الشكل 3 كيف ترتبط هذه الحدود عندما يعرض SageMaker Unified Studio موارد SageMaker HyperPod المعتمدة لأعضاء المشروع.
الشكل 3: نموذج إدارة SageMaker HyperPod الموصى به. يحكم SageMaker Unified Studio سياق التعاون، بينما تبقى هوية المجموعة وتفويض حمل العمل وسياسة الجدول والضوابط التشغيلية منفصلة.
حدّد متى يكون SageMaker Unified Studio تجربة الإدارة المناسبة
مع SageMaker Unified Studio، يمكن لفرق تعلم الآلة التي تعمل بالفعل ضمن مشروع أن تتبع مسارًا معتمدًا للوصول إلى موارد SageMaker HyperPod المشتركة. يمكن للأعضاء العثور على المجموعات المتصلة، ومراجعة الحالة والبيانات الوصفية، وفحص المهام والمقاييس المدعومة، والانتقال إلى JupyterLab دون استخدام جرد بنية تحتية منفصل.
لا تحل هذه التجربة محل إدارة المجموعة. يوضح الجدول التالي كيف يجب على كل شخصية استخدام SageMaker Unified Studio إلى جانب الواجهات الخاصة بالخدمة.
| الشخصية | استخدام SageMaker Unified Studio لـ | الاستمرار في استخدام الأدوات الخاصة بالخدمة لـ |
| مسؤول النطاق أو البنية التحتية | وحدات النطاق، وسياسة إنشاء المشاريع، وملفات تعريف المشاريع، وسياسة العضوية، وموضع الحساب | الضوابط على مستوى المؤسسة، وتوفير الحسابات، وأتمتة البنية التحتية |
| مسؤول مجموعة SageMaker HyperPod | عرض اتصالات المجموعات المعتمدة ومراجعة طرق عرض المجموعة والمهام والإعدادات والبيانات الوصفية | إنشاء المجموعة وتحديثاتها وتكوين المرونة والإضافات وإدارة EKS أو Slurm والاستجابة للحوادث |
| مالك المشروع | إدارة عضوية المشروع ومنح المستخدمين سياق مشروع متسق لموارد الحوسبة المعتمدة | طلب تغييرات على البنية التحتية والموافقة على متطلبات الوصول الخاصة بالأعمال |
| مهندس تعلم آلة أو عالم بيانات | العثور على موارد الحوسبة المعتمدة ومراجعة حالة حمل العمل وفتح سير عمل JupyterLab | إرسال حمل العمل التفصيلي وإدارته عبر SageMaker HyperPod CLI, kubectlأو أدوات Slurm حسب الاقتضاء |
استخدم SageMaker Unified Studio عندما تحتاج عضوية المشروع، والوصول إلى البيانات، وأدوات التطوير، والحوسبة إلى سياق مشترك. لتغييرات المجموعة والأتمتة القابلة للتكرار، واصل استخدام واجهات SageMaker AI APIs، والبنية التحتية ككود، وأدوات التنسيق. للرجوع إلى التطبيقات المرجعية والتكاملات، راجع AI on SageMaker HyperPod الموقع.
اتخذ قرارات البنية التحتية قبل ربط مجموعة
قبل الموافقة على الاتصال، وثّق حساب السعة، وأي حسابات مستهلكين أو بيانات، ومنطقة AWS، ومسارات الشبكة، والهويات، والمالكين، وحدود أحمال العمل، ومتطلبات العزل. إذا كنت بحاجة إلى إرشادات لإنشاء مجموعة، راجع وثائق Amazon SageMaker HyperPod أو موقع AI on SageMaker HyperPod.
افصل بين الهويات الإدارية وهويات عبء العمل. حافظ على التمييز في SageMaker HyperPod بين مسؤولي المجموعة ومستخدمي علماء البيانات عند إنشاء أدوار المشروع وأدوار الوصول. لا ينبغي أن يتلقى دور موجّه للمشروع أذونات دورة حياة المجموعة لمجرد أن مستخدميه يشغّلون أعباء عمل. راجع AWS Identity and Access Management for SageMaker HyperPod للإطلاع على نموذج الأذونات المدعوم.
تعامل مع الشبكات كتحكم من البداية إلى النهاية. قيّد الوصول إلى نقطة نهاية Kubernetes API في Amazon EKS إلى مسارات الشبكة الإدارية المعتمدة، وتحكّم في دخول وخروج الـ pods، وتحقق من أن دور المشروع ودور الاتصال ودور عبء العمل وشبكة المجموعة تدعم مسارات البيانات المقصودة فقط. للتكوين الخاص بالمنسّق، راجع Orchestrating SageMaker HyperPod clusters with Amazon EKS.
على سبيل المثال، هيّئ الوصول الخاص إلى نقطة نهاية Amazon EKS API واسمح به فقط من الشبكات الفرعية (subnets) المعتمدة للمسؤولين أو أعباء العمل. طبّق سياسة رفض افتراضية في Kubernetes NetworkPolicy واسمح صراحةً بمسارات الخدمة-إلى-الخدمة ومسارات الخروج المطلوبة. استخدم نقاط نهاية الشبكة الافتراضية الخاصة (VPC) للخدمات مثل Amazon S3 وAmazon Elastic Container Registry (Amazon ECR) وAmazon CloudWatch حيثما كان ذلك مناسبًا، وامنح كل مستأجر دور عبء عمل مخصصًا للوصول إلى البيانات.
أنشئ عقد اتصال. عقد الاتصال هو سجل حوكمة يديره العميل، مثل صفحة ويكي أو تذكرة أو سجل كتالوج خدمات أو ملف متتبع في مستودع بنية تحتية ككود. إنه ليس ميزة من ميزات المنصة. سجّل المعلومات التالية لكل اتصال معتمد بين مشروع ومجموعة:
- المالك التجاري، ومالك العمليات، ومالك التكلفة.
- وحدة النطاق (domain unit) والمشروع في SageMaker Unified Studio.
- حساب المجموعة والمنطقة والاسم والمنسّق.
- دور المشروع واسم المورد من Amazon (ARN) لدور الوصول المستخدم في الاتصال.
- أنواع أعباء العمل المعتمدة وتصنيف البيانات.
- مساحات الأسماء في EKS أو نطاق الوصول إلى Slurm.
- سياسة الجدولة ومالك الاستثناءات.
- توقعات المراقبة والدعم وإيقاف التشغيل.
يوفر هذا العقد سجلًا واحدًا للمراجعين لتقييم المسار الكامل للوصول والموافقة عليه.
حاكِ الهوية وظهور المهام
تحكّم في كل من الإجراءات والرؤية. الإعداد غير الصحيح لأسماء المهام ومساحات الأسماء وطلبات الموارد وأنماط الاستخدام يمكن أن يكشف معلومات عن عمل فريق آخر.
استخدم المجموعات بدلاً من المنح الفردية لعضوية المشروع والوصول إلى المجموعة حيثما أمكن. راجع كل دور عند حدوده الخاصة بدلاً من إنشاء دور واسع واحد يمتد عبر النطاق والمشروع والمجموعة وسياسة عبء العمل.
يوضح سير العمل التالي كيفية فصل ما يمكن للمستخدم رؤيته عما يمكن للمستخدم فعله.
الشكل 4: حوكمة الهوية وظهور المهام. خصّص الوصول من خلال المجموعات، وقيّد نطاق كل دور بحدوده، وقيّد ظهور المهام، وافصل بين القدرة على رؤية العمل والقدرة على التصرف بناءً عليه.
راجع ظهور المهام الافتراضي قبل ضم المستخدمين. تشرح وثائق SageMaker HyperPod في SageMaker AI Studio أن مستخدمي SageMaker AI Studio يمكنهم رؤية جميع مهام مجموعة Amazon EKS افتراضيًا. أما بالنسبة لمجموعات Slurm، فيمكن لكل مستخدم من SageMaker AI Studio عرض المهام المتاحة وإدارتها والتفاعل معها. هيّئ قيود عرض المهام قبل ضم فرق متعددة: راجع Restrict task view in Studio for EKS clusters بالنسبة إلى Amazon EKS و Restrict task view in Studio for Slurm clusters بالنسبة إلى Slurm. عضوية المشروع ليست حدودًا أمنية على مستوى المجموعة.
بالنسبة إلى مجموعات Amazon EKS، اربط كل فريق بمساحة أسماء معتمدة وأذونات RBAC، واربط كل حساب خدمة لعبء العمل بدور IAM خاص بالمستأجر. للوصول إلى البيانات عبر الحسابات، اربط حساب الخدمة بدور EKS Pod Identity في حساب السعة (المجموعة) وحدّد دور IAM هدفًا على الاقتران (targetRoleArn). يقوم EKS Pod Identity بعد ذلك بتنفيذ افتراض الدور عبر الحسابات تلقائيًا، بحيث لا يحتاج كود التطبيق إلى استدعاء AssumeRole. يقع الدور الهدف في حساب المستهلك أو حساب البيانات. حافظ على فصل رؤية القراءة فقط عن الأذونات لإنشاء أعباء العمل أو تحديثها أو حذفها. بالنسبة إلى مجموعات Slurm، عرّف ضوابط مكافئة للمستخدم والحساب والقسم (partition) ونظام الملفات وظهور المهام.
على سبيل المثال، يمنح دور Kubernetes RBAC التالي فريقًا صلاحية وصول للقراءة فقط إلى المهام في مساحة الأسماء الخاصة به فقط. ويُطلب دور منفصل لإنشاء أحمال العمل أو حذفها، مما يحافظ على فصل "الرؤية" عن "التنفيذ".
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: team-research
name: research-job-viewer
rules:
- apiGroups: ["batch"]
resources: ["jobs"]
verbs: ["get", "list", "watch"]
- apiGroups: ["kubeflow.org"]
resources: ["pytorchjobs"]
verbs: ["get", "list", "watch"]ترجمة أولويات الأعمال إلى سياسة جدولة
بالنسبة لمجموعات Amazon EKS، طبِّق حوكمة المهام فقط بعد تفعيل ضوابط الهوية والوصول إلى أحمال العمل.
يوضح الشكل التالي بوضوح القرارين المعنيين.
الشكل 5: حافظ على فصل التخويل عن سياسة الجدولة. يحدد EKS RBAC أو قوائم التحكم بالوصول Slurm ACLs ما إذا كان بإمكان المستخدم إرسال عبء عمل. تحدد حوكمة المهام في SageMaker HyperPod لـ Amazon EKS أو ضوابط الجدولة الأصلية في Slurm متى يحصل على الموارد الحسابية.
القدرة المضمونة والمشتركة الموثقة، وفئات الأولوية، وما إذا كان بإمكان فريق استخدام التخصيص الخامل لفريق آخر. عيّن مسؤولاً لكل استثناء. تنطبق حوكمة المهام أيضاً على مساحات SageMaker HyperPod (بيئات JupyterLab أو Code Editor مستقلة تعمل مباشرة على العنقود)، لذا أدرج أحمال التطوير التفاعلية هذه في سياسة التخصيص.
على سبيل المثال، على عنقود Amazon EKS، قد تمنح فريق التدريب الإنتاجي تخصيصاً مضموناً بنسبة 60 بالمئة مع فئة أولوية عالية، وتسمح لفريق البحث باقتطاع القدرة الخاملة بأولوية أقل، وتسمح باستباق تلك القدرة المقتطعة عندما يقدم فريق الإنتاجية أعمالاً. عيّن مسؤولاً واحداً للموافقة على أي استثناء من هذه السياسة حتى لا تتحول الطلبات لمرة واحدة بهدوء إلى قاعدة.
احتفظ بالتفويض وسياسة الجدولة منفصلين. تحدد RBAC في EKS أو قوائم ACL في Slurm ما إذا كان بإمكان مستخدم تقديم حمل عمل. أما حوكمة مهام SageMaker HyperPod لـ Amazon EKS، أو ضوابط جدولة Slurm الأصلية، فتحدد متى يتلقى حمل العمل المفوض موارد الحوسبة. استخدام حصة المجدول كضبط للوصول، أو استخدام ضوابط التفويض كسياسة جدولة، ينتج سلوكاً غير واضح ويجعل تشخيص الحوادث أصعب.
يشرح المقال أفضل الممارسات لحوكمة مهام Amazon SageMaker HyperPod أوزان الحصة العادلة والحصص والإقراض والاقتراض وفئات الأولوية وسيناريوهات التخصيص الشائعة. لعناقيد Amazon EKS، استخدم تلك الأنماط عند تعريف سياسة التخصيص. لعناقيد Slurm، استخدم ضوابط المجدول الأصلية الموصوفة سابقاً.
استخدم الملاحظة كحلقة تغذية راجعة للحوكمة
مع SageMaker Unified Studio، يمكنك عرض تفاصيل عنقود SageMaker HyperPod للمهام والمقاييس والإعدادات والبيانات الوصفية. لعناقيد Amazon EKS، تشمل مقاييس حوكمة المهام عروض العتاد والفرق والمهام. تساعدك هذه العروض على مقارنة نية السياسة بالاستهلاك الفعلي.
تعامل مع الملاحظة كحلقة، كما هو موضح في الشكل التالي.
الشكل 6: الملاحظة كحلقة تغذية راجعة للحوكمة. راقب الإشارات وقارنها بنية السياسة وقرر استجابة واضبط السياسة والتخصيصات، مع تعيين مسؤول واستجابة لكل إشارة.
عيّن مسؤولاً واستجابة لكل إشارة تراقبها. الأمثلة التالية تحول بيانات لوحة المعلومات إلى قرارات إدارية.
| الإشارة | القرار الإداري |
| سعة العنقود واستخدام المسرعات | تحديد ما إذا كان الاستخدام المنخفض مؤقتاً أو ناتجاً عن السياسة أو سببه قيود حمل العمل |
| تخصيص الفريق واستخدامه | مراجعة ما إذا كانت القدرة المحجوزة والمشتركة لا تزال تعكس طلب الأعمال |
| وقت تشغيل المهمة ووقت الانتظار | التحقيق في سياسة الأولوية أو حجم حمل العمل أو التنافس على السعة |
| المهام المعلقة والمستبقة | التأكد من أن نتائج المجدول تطابق نموذج الأولوية المعتمد |
| صحة العقد وأحداث الاسترداد | تفعيل عملية حوادث العنقود والتحقق من أهداف الاسترداد |
لعناقيد Amazon EKS، يعرض جدول المهام مهام Kubeflow (PyTorch وMPI وTensorFlow)، وتُعرض مهام PyTorch افتراضياً. قد لا تظهر الأحمال المقدمة عبر آليات أخرى هناك. لعناقيد Slurm، تعرض جداول المهام الوظائف في قائمة انتظار المجدول الحالية، بينما يوفر Slurm accounting بيانات الوظائف التاريخية عبر أدوات مثل sacct. عيّن من أين تحصل على بيانات المهام التاريخية وأدلة التدقيق وتفاصيل الحوادث.
إضافة Amazon CloudWatch Observability لـ EKS مطلوبة لعرضات المقاييس الموثقة. وللإضافة متطلباتها الأساسية الخاصة: الإصدار 2.4.0 أو أحدث، وسياسة IAM CloudWatchAgentServerPolicy المرفقة بدور عقدة العامل في Kubernetes. مقاييس Kueue، التي توفر عرضات حوكمة المهام، قد تترتب عليها رسوم مقاييس CloudWatch بعد الطبقة المجانية. راجع وثائق لوحة معلومات SageMaker HyperPod للاطلاع على اعتبارات الإعداد والتسعير الحالية.
راجع الاتصالات طوال دورة حياتها
حدِّد جدولاً زمنياً للمراجعة لكل اتصال. وعرِّف أيضاً مراجعات مبنية على الأحداث عند التغييرات في ملكية المشروع، أو أدوار الوصول، أو الحساب أو المنطقة (Region)، أو سعة العنقود، أو إصدار المنسِّق، أو تصنيف البيانات، أو تغطية المراقبة. استخدم عقد الاتصال لتسجيل كل قرار.
يوضح الشكل التالي مراحل دورة الحياة.
الشكل 7: دورة حياة الاتصال. اعتمد الاتصال بعقد اتصال موثَّق، ثم شغِّله وراقبه، وراجعه وفق جدول زمني وعند أحداث محددة، ثم جدِّده أو أبطلْه.
أتمت عملية الجرد وجمع الأدلة حيث إن ذلك يقلل العمل اليدوي، لكن أبقِ الاعتماد بمسؤولية المديرين المسؤولين. وأبطل الاتصالات التي لم تعد لها غرض تجاري أو مالك مسؤول.
الخاتمة
مع Amazon SageMaker Unified Studio، يمكن لفرق تعلم الآلة اتباع مسار قائم على المشروع للوصول إلى موارد SageMaker HyperPod المعتمدة مع احتفاظ فرق البنية التحتية بالتحكم في العنقود المركزي. ابدأ بعنقود واحد غير إنتاجي ومشروع تجريبي. قم بتكوين هوية عبء العمل، أو نطاق namespace أو Slurm، وأذونات البيانات، وسياسة الشبكة، وقيود عرض المهام، وحوكمة المهام لـ Amazon EKS أو عناصر جدولة Slurm الأصلية قبل إضافة الأعضاء. قم بتثبيت إضافة Amazon CloudWatch Observability لـ EKS حتى تمتلئ طرق عرض المقاييس، وسجّل الموافقة الكاملة في عقد الاتصال. استخدم أدوارًا عبر الحسابات للحسابات الاستهلاكية المعتمدة، واستخدم بنية تحتية مخصصة عند الحاجة إلى عزل صارم. اتبع إجراء الاتصال بـ SageMaker HyperPod لخطوات التنفيذ.