Amazon SageMaker HyperPod gibt Machine-Learning-Teams (ML) Zugriff auf große Pools beschleunigter Rechenleistung zum Training und Fine-Tuning von Modellen. Wenn sich mehrere Teams einen Cluster teilen, ist das technische Setup meist unkompliziert. Die Herausforderung ist die Governance. Sie müssen entscheiden, welche Teams den Cluster nutzen dürfen, wie viel Kapazität jedes Team erhält, was geschieht, wenn die Workload eines Teams mit der eines anderen konkurriert, und wer verantwortlich ist, wenn die Nutzung von der Richtlinie abweicht. Amazon SageMaker Unified Studio fügt eine weitere Überlegung hinzu: Sie können einen SageMaker-HyperPod-Cluster mit einem Projekt verbinden, sodass Teammitglieder Workloads aus ihrem Projekt-Workspace starten können. Dieser Komfort ist wertvoll, doch sobald mehrere teams Einblick in denselben Cluster haben, werden die Kontrollen, die regeln, wer was tun darf, noch wichtiger. In diesem Beitrag zeigen wir, wie Sie SageMaker HyperPod über SageMaker Unified Studio verwalten und dabei die zugrunde liegenden Governance-Kontrollen bewahren. Wir behandeln die vier Steuerungsebenen: Organisation, Projekt, Cluster und Workload. Außerdem erklären wir, wie Sie Identity-, Kapazitäts- und Observability-Richtlinien über diese Ebenen hinweg gestalten. Am Ende haben Sie ein wiederholbares Modell, um genehmigte SageMaker-HyperPod-Rechenleistung ML-Teams im Kontext ihres Projekts anzubieten und gleichzeitig die Cluster-Betriebsverantwortung beim Infrastrukturteam zu belassen.
Amazon SageMaker HyperPod ist eine Funktion von Amazon SageMaker AI. Amazon SageMaker Unified Studio ist die Daten- und KI-Entwicklungsumgebung, in der Teams mit ihren Daten und Tools arbeiten. Mit SageMaker Unified Studio können Sie ein Projekt mit einem bestehenden SageMaker-HyperPod-Cluster verbinden. Mitglieder können dann Machine-Learning-Workloads starten, Cluster- und Aufgabeninformationen einsehen und einen JupyterLab-Workflow öffnen. Sie verwalten Cluster weiterhin über die Schnittstellen und APIs von Amazon SageMaker AI.
Diese Trennung bietet Infrastrukturteams ein praktisches Betriebsmodell. Sie können die Cluster-Infrastruktur über etablierte Cloud-Betriebsprozesse verwalten. Gleichzeitig können Sie genehmigte Rechenleistung Machine-Learning-Teams im Kontext ihres Projekts bereitstellen. In diesem Beitrag beschreiben wir, wie Sie Infrastrukturgrenzen entwerfen, den Zugriff steuern, gemeinsame Kapazitäten zuweisen und SageMaker HyperPod konsistent über SageMaker Unified Studio betreiben können.
Verstehen Sie die administrativen Grenzen
Eine gut regierte Umgebung trennt organisationsweite Verwaltung, Projektzugriff und Cluster-Betrieb. Jede Ebene beantwortet eine andere Frage und verwendet eine andere Kontrolle. Die folgende Tabelle fasst jede Grenze, ihre primären Kontrollen und ihren administrativen Zweck zusammen.
| Grenze | Primäre Kontrollen | Administrativer Zweck |
| Organisation | SageMaker Unified Studio Domains, Domain-Units, zugeordnete Konten, Projektprofile und Autorisierungsrichtlinien | Bestimmt, wer Projekte erstellen darf, welche Konten und Regionen Projekte verwenden dürfen und welche Tools verfügbar sind |
| Projekt | Projektmitgliedschaft, Projektrollen und SageMaker-HyperPod-Verbindungen | Definiert den Kollaborationskontext und die AWS-Ressourcen, auf die Projektmitglieder zugreifen können |
| Cluster | SageMaker-HyperPod-Cluster-Admin-Rollen, Amazon-EKS-Access-Entries, rollenbasierte Zugriffskontrolle (RBAC) und EKS Pod Identity oder Slurm-Kontrollen | Steuert Cluster-Konfiguration, Scheduler-Zugriff, Namespaces, Aufgaben und Infrastrukturoperationen |
| Workload | Compute-Zuweisungen, Prioritätsklassen, Lending- und Borrowing-Richtlinien und Aufgabenberechtigungen | Kontrolliert, wer Arbeit einreichen kann und wie gemeinsame Kapazität zugewiesen wird |
Betrachten Sie diese Kontrollen als Ebenen. Eine SageMaker-HyperPod-Verbindung fügt einem Projekt einen genehmigten Cluster hinzu. Sie ersetzt nicht die AWS Identity and Access Management (IAM)-, Amazon Elastic Kubernetes Service (Amazon EKS)- oder Slurm-Kontrollen des Clusters. Prüfen Sie die Projektrolle, die Verbindungs-Zugriffsrolle, EKS-Access-Entries und RBAC- oder Slurm-Kontrollen, die Workload-Identity, Daten- und AWS Key Management Service (AWS KMS)-Schlüssel richtlinien, Netzwerkrichtlinie, Aufgabenansichts-Beschränkungen und Scheduler-Richtlinie gemeinsam. Stellen Sie den Cluster erst verfügbar, wenn diese Kontrollen aufeinander abgestimmt sind.
Diese Kontrollen bilden vier Ebenen, wie in der folgenden Abbildung dargestellt.
Abbildung 1: Die vier Steuerungsebenen: Organisation, Projekt, Cluster und Workload. Jede Ebene beantwortet eine andere Frage und nutzt eine andere Steuerung, daher sollte jede an ihrer eigenen Grenze überprüft werden.
SageMaker Unified Studio Projekte sind Kollaborationsgrenzen. Sie sind keine starken Laufzeit-Sicherheitsgrenzen. Halten Sie den SageMaker HyperPod-Cluster, den Scheduler und die knappe Rechenzentrumskapazität unter einem einzigen ausgewiesenen Kapazitätskonto. Zugelassene Nutzer und Datensätze können im selben Konto oder in getrennten Verbraucher- und Datenkonten bleiben. AWS dokumentiert die Multi-Account-Unterstützung für SageMaker HyperPod Task Governance auf Amazon EKS-Clustern. Obwohl On-Demand Capacity Reservations kontenübergreifend geteilt werden können, zentralisieren Sie den Besitz des SageMaker HyperPod-Clusters und die Kapazitätsverwaltung im Kapazitätskonto. Verwenden Sie genehmigten kontenübergreifenden Zugriff, anstatt jedes Verbraucherkonto zu einem unabhängigen Kapazitätsadministrator zu machen.
- Verwenden Sie bei Amazon EKS pro Tenant (Mieter) einen eigenen Namespace zusammen mit RBAC, Service-Konten pro Tenant und EKS Pod Identity-Rollen, Default-Deny-Netzwerkrichtlinien sowie tenant-spezifische Storage- und AWS KMS-Berechtigungen. Verwenden Sie bei Slurm das Slurm-Accounting mit hierarchischen Accounts und Assoziationen, Quality of Service (QoS), Prioritäts- und Fair-Share-Richtlinien sowie Partitionen. Verwenden Sie außerdem Betriebssystem-Identitäten und Dateiberechtigungen, Netzwerkkontrollen und tenant-spezifische Datenpfade.
- Verwenden Sie IAM-Rollen und Ressourcenrichtlinien anstelle alleiniger Projektmitgliedschaften, um den Zugriff auf Amazon Simple Storage Service (Amazon S3)-Buckets, AWS KMS-Schlüssel, Secrets, Container-Registries und andere Datendienste zu steuern. Verwenden Sie Projekt- und Domäneneinheiten-Richtlinien für Zusammenarbeit und Delegation.
- Verwenden Sie für Amazon EKS-Cluster SageMaker HyperPod Task Governance, einschließlich Quotas, Prioritätsklassen, Lending and Borrowing und Preemption, um den zentralen Beschleuniger-Pool fair zu teilen. Verwenden Sie für Slurm-Cluster die nativen Kontrollen für Partitionen, Quality of Service (QoS), Priorität, Fair-Share und Preemption. Slurm bietet kein vergleichbares Lending-and-Borrowing-Modell. Diese Scheduling-Kontrollen bestimmen, wann eine autorisierte Workload Rechenleistung erhält. Sie gewähren keinen Namespace- oder Datenzugriff.
Verwenden Sie für eine stärkere Isolation innerhalb eines Clusters dedizierte Nodes oder Node Groups sowie wo angemessen Admission Controls. Verwenden Sie einen separaten Cluster oder Account, wenn gesetzliche, regulatorische oder Sicherheitsanforderungen eine harte Infrastruktur-Isolation erfordern. Cross-Account-Consumer-Zugriff kann die Eigentümerschaft auf Account-Ebene bewahren, ohne den zentralen SageMaker HyperPod-Cluster zu duplizieren. Verwenden Sie innerhalb des Capacity-Accounts Projektprofile und Domäneneinheiten mit Projekt-Autorisierungsrichtlinien, um Projekterstellung und Projekt-Eigentümerschaft zu delegieren.
Die folgende Abbildung zeigt zentralisierte Kapazität mit tenant-spezifischen Kontrollen für Workload, Identität, Daten, Netzwerk und Sichtbarkeit.
Abbildung 2: Zentralisierte SageMaker HyperPod-Kapazität. Cluster und Scheduler verbleiben in einem Capacity-Account. Jeder Tenant erhält Kontrollen für Workload, Identität, Daten, Netzwerk und Task-Sichtbarkeit. Hard-Isolation-Anforderungen verwenden dedizierte Infrastruktur.
Abbildung 3 zeigt, wie diese Grenzen zusammenwirken, wenn SageMaker Unified Studio genehmigte SageMaker HyperPod-Rechenleistung für Projektmitglieder bereitstellt.
Abbildung 3: Empfohlenes Verwaltungsmodell für SageMaker HyperPod. SageMaker Unified Studio steuert den Zusammenarbeitskontext, während Cluster-Identität, Workload-Autorisierung, Scheduler-Richtlinie und operationale Kontrollen getrennt bleiben.
Entscheiden Sie, wann SageMaker Unified Studio die richtige Verwaltungserfahrung ist
Mit SageMaker Unified Studio können Machine-Learning-Teams, die bereits in einem Projekt arbeiten, einen genehmigten Pfad zu geteilter SageMaker HyperPod-Rechenleistung nutzen. Mitglieder können verbundene Cluster finden, Status und Metadaten einsehen, unterstützte Tasks und Metriken prüfen und ohne ein separates Infrastrukturverzeichnis in JupyterLab wechseln.
Diese Erfahrung ersetzt nicht die Clusterverwaltung. Die folgende Tabelle zeigt, wie jede Persona SageMaker Unified Studio neben den dienstspezifischen Schnittstellen nutzen sollte.
| Persona | SageMaker Unified Studio verwenden für | Weiterhin dienstspezifische Tools verwenden für |
| Domain- oder Infrastruktur-Administrator | Domäneneinheiten, Richtlinie zur Projekterstellung, Projektprofile, Mitgliedschaftsrichtlinie und Account-Platzierung | Kontrollen auf Organisationsebene, Account-Bereitstellung und Infrastruktur-Automatisierung |
| SageMaker HyperPod-Cluster-Administrator | Präsentieren genehmigter Clusterverbindungen und Prüfen von Cluster-, Task-, Einstellungs- und Metadatenansichten | Cluster-Erstellung, Updates, Resilienz-Konfiguration, Add-ons, EKS- oder Slurm-Verwaltung und Incident Response |
| Projektverantwortlicher | Verwalten der Projektmitgliedschaft und Bereitstellen eines konsistenten Projektkontexts für genehmigte Rechenleistung | Anfordern von Infrastrukturänderungen und Genehmigen geschäftsspezifischer Zugriffsanforderungen |
| ML-Engineer oder Data Scientist | Finden genehmigter Rechenleistung, Prüfen des Workload-Status und Öffnen des JupyterLab-Workflows | Einreichen und Verwalten detaillierter Workloads über die SageMaker HyperPod CLI, kubectl, Slurm-Tools oder je nach Bedarf passende Werkzeuge |
Verwenden Sie SageMaker Unified Studio, wenn Projektmitgliedschaft, Datenzugriff, Entwicklungstools und Compute einen gemeinsamen Kontext benötigen. Für Cluster-Änderungen und wiederholbare Automatisierung verwenden Sie weiterhin SageMaker AI APIs, Infrastructure as Code und Orchestrator-Tools. Referenzimplementierungen und Integrationen finden Sie auf der AI on SageMaker HyperPod -Website.
Treffen Sie Infrastruktur-Entscheidungen, bevor Sie einen Cluster verbinden
Dokumentieren Sie vor der Genehmigung einer Verbindung das Kapazitätskonto, etwaige Consumer- oder Datenkonten, die AWS-Region, Netzwerkpfade, Identitäten, Verantwortliche, Workload-Grenzen und Isolationsanforderungen. Wenn Sie Anleitung zum Erstellen eines Clusters benötigen, lesen Sie die Amazon SageMaker HyperPod-Dokumentation oder die AI on SageMaker HyperPod-Website.
Trennen Sie administrative Identitäten von Workload-Identitäten. Bewahren Sie die SageMaker-HyperPod-Unterscheidung zwischen Cluster-Administratoren und Data-Scientist-Benutzern bei der Erstellung von Projekt- und Zugriffsrollen. Eine projektbezogene Rolle sollte keine Berechtigungen für den Cluster-Lebenszyklus allein deshalb erhalten, weil ihre Benutzer Workloads ausführen. Beachten Sie die Informationen unter AWS Identity and Access Management für SageMaker HyperPod zum unterstützten Berechtigungsmodell.
Behandeln Sie Netzwerk 作为 durchgängiges Kontrollpunkt – sorry, korrekt: Betrachten Sie Netzwerk als durchgängiges Kontrollelement. Beschränken Sie den Zugriff auf den Amazon-EKS-Kubernetes-API-Endpunkt auf genehmigte administrative Netzwerkpfade, kontrollieren Sie Pod-Ingress und Pod-Egress und stellen Sie sicher, dass die Projekt-, Verbindungs-, Workload-Rolle und das Cluster-Netzwerk nur die vorgesehenen Datenpfade unterstützen. Informationen zur orchestratorspezifischen Konfiguration finden Sie unter Orchestrierung von SageMaker-HyperPod-Clustern mit Amazon EKS.
Konfigurieren Sie beispielsweise privaten Zugriff auf den Amazon-EKS-API-Endpunkt und erlauben Sie ihn nur aus genehmigten Administrator- oder Workload-Subnetzen. Wenden Sie eine Kubernetes-Standard-Deny-Richtlinie an NetworkPolicy und erlauben Sie ausdrücklich nur die erforderlichen Service-zu-Service- und Egress-Pfade. Verwenden Sie nach Möglichkeit Virtual Private Cloud (VPC)-Endpunkte für Dienste wie Amazon S3, Amazon Elastic Container Registry (Amazon ECR) und Amazon CloudWatch und geben Sie jedem Mandanten eine dedizierte Workload-Rolle für den Datenzugriff.
Erstellen Sie einen Verbindungsvertrag. Ein Verbindungsvertrag ist ein kundenseitig verwalteter Governance-Datensatz, z. B. eine Wiki-Seite, ein Ticket, ein Service-Catalog-Eintrag oder eine Datei in einem Infrastructure-as-Code-Repository. Es handelt sich nicht um eine Plattformfunktion. Erfassen Sie die folgenden Informationen für jede genehmigte Projekt-zu-Cluster-Verbindung:
- Business Owner, Operations Owner und Cost Owner.
- SageMaker Unified Studio Domain-Unit und Projekt.
- Cluster-Konto, Region, Name und Orchestrator.
- Projektrolle und die von der Verbindung verwendete Amazon Resource Name (ARN) der Zugriffsrolle.
- Genehmigte Workload-Typen und Datenklassifizierung.
- EKS-Namespaces oder Slurm-Zugriffsumfang.
- Scheduling-Richtlinie und Ausnahme-Owner.
- Erwartungen zu Monitoring, Support und Außerbetriebnahme.
Dieser Vertrag gibt Prüfern einen einzigen Datensatz zur Bewertung und Genehmigung des vollständigen Zugriffspfads.
Identitäten und Aufgabensichtbarkeit governance – korrekt: Identitäten und Aufgabensichtbarkeit steuern
Steuern Sie sowohl Aktionen als auch Sichtbarkeit. Eine unsachgemäße Einrichtung von Aufgabennamen, Namespaces, Ressourcenanforderungen und Nutzungsmustern kann Informationen über die Arbeit eines anderen Teams offenlegen.
Verwenden Sie nach Möglichkeit Gruppen anstelle von individuellen Berechtigungen für die Projektmitgliedschaft und den Cluster-Zugriff. Prüfen Sie jede Rolle an ihrer eigenen Grenze, statt eine einzige breite Rolle zu erstellen, die Domain, Projekt, Cluster und Workload-Richtlinie umspannt.
Der folgende Workflow zeigt, wie man trennt, was ein Benutzer sehen kann, von dem, was ein Benutzer tun kann.
Abbildung 4: Steuerung von Identitäten und Aufgabensichtbarkeit. Gewähren Sie Zugriff über Gruppen, beschränken Sie jede Rolle auf ihre Grenze, schränken Sie die Aufgabensichtbarkeit ein und trennen Sie die Fähigkeit, Arbeit zu sehen, von der Fähigkeit, auf sie einzuwirken.
Prüfen Sie die Standard-Aufgabensichtbarkeit, bevor Sie Benutzer onboarden. Die Dokumentation für SageMaker HyperPod in SageMaker AI Studio erklärt, dass SageMaker-AI-Studio-Benutzer standardmäßig alle Amazon-EKS-Cluster-Aufgaben sehen können. Bei Slurm-Clustern kann jeder SageMaker-AI-Studio-Benutzer verfügbare Aufgaben anzeigen, verwalten und mit ihnen interagieren. Konfigurieren Sie Einschränkungen der Aufgabenansicht, bevor Sie mehrere Teams onboarden: siehe Einschränken der Aufgabenansicht in Studio für EKS-Cluster für Amazon EKS und Einschränken der Aufgabenansicht in Studio für Slurm-Cluster für Slurm. Die Projektmitgliedschaft ist keine Sicherheitsgrenze auf Cluster-Ebene.
Ordnen Sie für Amazon-EKS-Cluster jedes Team einem genehmigten Namespace und RBAC-Berechtigungen zu und ordnen Sie jedes Workload-Servicekonto einer mandantenspezifischen IAM-Rolle zu. Für datenübergreifenden kontenübergreifenden Zugriff verknüpfen Sie das Servicekonto mit einer EKS-Pod-Identity-Rolle im Kapazitätskonto (Cluster-Konto) und legen Sie eine Ziel-IAM-Rolle für die Zuordnung fest (targetRoleArn). EKS Pod Identity führt dann die kontenübergreifende Rollenübernahme automatisch durch, sodass Anwendungscode nicht aufrufen muss AssumeRole. Die Zielrolle befindet sich im Verbraucher- oder Datenkonto. Halten Sie die Lese-Sichtbarkeit von Berechtigungen zum Erstellen, Aktualisieren oder Löschen von Workloads getrennt. Definieren Sie für Slurm-Cluster entsprechende Kontrollen für Benutzer, Konten, Partitionen, Dateisysteme und die Aufgabensichtbarkeit.
Die folgende Kubernetes-RBAC-Role gewährt einem Team beispielsweise schreibgeschützten Zugriff auf Jobs ausschließlich in seinem eigenen Namespace. Eine separate Rolle ist erforderlich, um Workloads zu erstellen oder zu löschen, wodurch „Sehen“ von „Handeln“ getrennt bleibt.
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"]Geschäftsprioritäten in eine Scheduling-Richtlinie übersetzen
Wenden Sie bei Amazon EKS-Clustern Task Governance erst an, wenn Identitäts- und Workload-Zugriffskontrollen eingerichtet sind.
Die folgende Abbildung trennt die beiden Entscheidungen, die damit verbunden sind.
Abbildung 5: Autorisierung und Scheduling-Richtlinie getrennt halten. EKS RBAC oder Slurm-ACLs bestimmen, ob ein Benutzer eine Workload einreichen kann. SageMaker HyperPod task governance für Amazon EKS oder native Slurm-Scheduling-Kontrollen bestimmen, wann sie Rechenressourcen erhält.
Dokumentierte garantierte und gemeinsame Kapazität, Prioritätsklassen und ob ein Team die ungenutzte Zuweisung eines anderen Teams nutzen darf. Weisen Sie jeder Ausnahme einen Verantwortlichen zu. Die Task-Governance gilt auch für SageMaker HyperPod spaces (in sich geschlossene JupyterLab- oder Code-Editor-Umgebungen, die direkt auf dem Cluster ausgeführt werden), sodass Sie diese interaktiven Entwicklungs-Workloads in die Zuweisungsrichtlinie einbeziehen sollten.
Beispielsweise könnten Sie auf einem Amazon EKS-Cluster dem Produktions-Training-Team eine garantierte Zuweisung von 60 Prozent mit einer hohen Prioritätsklasse geben, dem Forschungsteam erlauben, ungenutzte Kapazität mit einer niedrigeren Priorität auszuleihen, und die Preemption dieser geliehenen Kapazität zulassen, wenn das Produktionsteam Workloads einreicht. Weisen Sie einen Verantwortlichen zu, der jede Ausnahme von dieser Richtlinie genehmigt, damit einmalige Anfragen nicht unbemerkt zur Norm werden.
Halten Sie Autorisierung und Scheduling-Richtlinie getrennt. EKS RBAC oder Slurm-ACLs bestimmen, ob ein Benutzer einen Workload einreichen kann. SageMaker HyperPod task governance für Amazon EKS oder native Slurm-Scheduling-Steuerungen bestimmen, wann dieser autorisierte Workload Rechenleistung erhält. Die Verwendung von Scheduler-Quoten als Zugriffssteuerung oder von Autorisierungssteuerungen als Scheduling-Richtlinie führt zu unklarem Verhalten und macht Vorfälle schwieriger zu diagnostizieren.
Der Beitrag Best practices for Amazon SageMaker HyperPod task governance erklärt Fair-Share-Gewichtungen, Kontingente, Lending und Borrowing, Prioritätsklassen und gängige Zuweisungsszenarien. Verwenden Sie für Amazon EKS-Cluster diese Muster beim Definieren der Zuweisungsrichtlinie. Verwenden Sie für Slurm-Cluster die zuvor beschriebenen nativen Scheduler-Steuerungen.
Nutzen Sie Observability als Governance-Rückkopplungsschleife
Mit SageMaker Unified Studio können Sie SageMaker HyperPod-Clusterdetails für Aufgaben, Metriken, Einstellungen und Metadaten anzeigen. Für Amazon EKS-Cluster umfassen die Task-Governance-Metriken Hardware-, Team- und Task-Ansichten. Diese Ansichten helfen Ihnen, die Richtlinienabsicht mit dem tatsächlichen Verbrauch zu vergleichen.
Behandeln Sie Observability als Schleife, wie in der folgenden Abbildung gezeigt.
Abbildung 6: Observability als Governance-Rückkopplungsschleife. Überwachen Sie Signale, vergleichen Sie sie mit der Richtlinienabsicht, entscheiden Sie über eine Reaktion und passen Sie Richtlinien und Zuweisungen an, indem Sie jedem Signal einen Verantwortlichen und eine Reaktion zuordnen.
Definieren Sie für jedes überwachte Signal einen Verantwortlichen und eine Reaktion. Die folgenden Beispiele verwandeln Dashboard-Daten in administrative Entscheidungen.
| Signal | Administrative Entscheidung |
| Cluster-Kapazität und Beschleuniger-Auslastung | Bestimmen Sie, ob eine niedrige Auslastung vorübergehend, richtlinienbedingt oder durch Workload-Einschränkungen verursacht ist |
| Team-Zuweisung und -Auslastung | Überprüfen Sie, ob reservierte und gemeinsame Kapazität weiterhin dem Geschäftsbedarf entspricht |
| Task-Laufzeit und Wartezeit | Untersuchen Sie Prioritätsrichtlinie, Workload-Dimensionierung oder Kapazitätskonkurrenz |
| Ausstehende und vorzeitig beendete Tasks | Bestätigen Sie, dass die Scheduler-Ergebnisse dem genehmigten Prioritätsmodell entsprechen |
| Node-Integrität und Wiederherstellungsereignisse | Lösen Sie den Cluster-Vorfallsprozess aus und validieren Sie die Wiederherstellungsziele |
Bei Amazon EKS-Clustern zeigt die Task-Tabelle Kubeflow-Tasks (PyTorch, MPI und TensorFlow) an, wobei PyTorch-Tasks standardmäßig angezeigt werden. Über andere Mechanismen eingereichte Workloads erscheinen dort möglicherweise nicht. Bei Slurm-Clustern zeigen Task-Tabellen die Jobs in der aktuellen Scheduler-Warteschlange an, während das Slurm-Accounting historische Jobdaten über Tools wie sacctbereitstellt. Legen Sie fest, wo Sie historische Taskdaten, Audit-Nachweise und Vorfalldetails beziehen.
Das Amazon CloudWatch Observability EKS Add-on ist für die dokumentierten Metrikansichten erforderlich. Das Add-on hat eigene Voraussetzungen: Version 2.4.0 oder höher, und die CloudWatchAgentServerPolicy IAM-Richtlinie, die der Kubernetes-Worker-Node-Rolle angehängt ist. Kueue-Metriken, die die Task-Governance-Ansichten liefern, können nach dem Free Tier CloudWatch-Metrikgebühren verursachen. Aktuelle Einrichtungs- und Preisüberlegungen finden Sie in der SageMaker HyperPod dashboard documentation für aktuelle Setup- und Preisaspekte.
Verbindungen über ihren gesamten Lebenszyklus überprüfen
Legen Sie einen Prüfplan für jede Verbindung fest. Definieren Sie außerdem ereignisgesteuerte Prüfungen für Änderungen am Projekteigentum, an Zugriffsrollen, am Konto oder an der Region, an der Cluster-Kapazität, an der Orchestrator-Version, an der Datenklassifizierung oder an der Überwachungsabdeckung. Verwenden Sie den Verbindungsvertrag, um jede Entscheidung festzuhalten.
Die folgende Abbildung zeigt die Lebenszyklusphasen.
Abbildung 7: Der Verbindungslebenszyklus. Genehmigen Sie eine Verbindung mit einem dokumentierten Verbindungsvertrag, betreiben und überwachen Sie sie, prüfen Sie sie planmäßig und bei definierten Ereignissen und verlängern oder widerrufen Sie sie anschließend.
Automatisieren Sie Bestandsaufnahme und Nachweiserhebung, wo dies manuelle Arbeit reduziert, aber belassen Sie die Genehmigung bei verantwortlichen Administratoren. Widerrufen Sie Verbindungen, die keinen geschäftlichen Zweck oder keinen verantwortlichen Eigentümer mehr haben.
Fazit
Mit Amazon SageMaker Unified Studio können Machine-Learning-Teams einen projektorientierten Weg zu genehmigter SageMaker HyperPod-Rechenleistung verfolgen, während Infrastrukturteams die Kontrolle über den zentralisierten Cluster behalten. Beginnen Sie mit einem Nicht-Produktions-Cluster und einem Testprojekt. Konfigurieren Sie Workload-Identität, Namespace- oder Slurm-Scope, Datenberechtigungen, Netzwerkrichtlinien, Task-View-Einschränkungen und Task-Governance für Amazon EKS bzw. native Planungssteuerungen für Slurm, bevor Sie Mitglieder hinzufügen. Installieren Sie das Amazon CloudWatch Observability EKS Add-on, damit Metrikansichten gefüllt werden, und dokumentieren Sie die vollständige Genehmigung im Verbindungsvertrag. Verwenden Sie Cross-Account-Rollen für genehmigte Consumer-Konten und dedizierte Infrastruktur, wenn eine harte Isolation erforderlich ist. Folgen Sie dem SageMaker HyperPod-Verbindungsverfahren für die Umsetzungsschritte.