Skip to main content
NetApp artificial intelligence solutions
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

10. Sicherheitsaspekte, Validierung und Tests

Beitragende nkarthik
Änderungen vorschlagen
PDFs

Karthikeyan Nagalingam, NetApp

Dieser kombinierte Abschnitt behandelt die erforderlichen Kontrollmechanismen für den sicheren Betrieb der KI-Pipeline sowie die Validierungsaktivitäten, mit denen nachgewiesen wird, dass sich das Design in repräsentativen Umgebungen wie erwartet verhält. Dieselbe Trennung der Storage-Tiers, das Zugriffsmodell mit minimalen Berechtigungen, die Prüfpunktlogik und die laufbezogene Datenherkunft, die in der Pipeline verwendet werden, fließen auch in den Validierungsplan und die betrieblichen Leitplanken ein.

[[10-1-security-considerations]]
== 10.1 Sicherheitsüberlegungen

Sicherheitsmaßnahmen sollten jede Speicherebene und Pipeline-Funktion isolieren und gleichzeitig die für Audits erforderliche Datenherkunft bewahren. Für StorageGRID Rohdaten, ONTAP NAS aufbereitete Daten, das ausgewählte XCP-Ziel und die StorageGRID Archivierung sollten separate Anmeldeinformationen mit minimalen Berechtigungen verwendet werden. Der Netzwerkverkehr sollte verschlüsselt und alle Geheimnisse außerhalb der DAG-Definition, der Beispiele und des Shell-Verlaufs gespeichert werden.

Bereich Empfehlung

Anmeldedatenverwaltung

Airflow Connections/Variables oder ein Secrets Manager sollten verwendet werden; Inline-Klartext in dag_run.conf ist zu vermeiden.

Daten während der Übertragung

TLS-fähige S3-Endpunkte und verschlüsselte NFS/Lustre Übertragung, sofern unterstützt

Zugangskontrolle

S3-Anmeldeinformationen pro Rolle (StorageGRID Rohdaten, ONTAP NAS aufbereitete Daten, XCP Ziel, StorageGRID Archivierung) auf die minimal erforderlichen Berechtigungen beschränken

Geheimnisse in Konfigurationen

Rotieren Sie alle während der Tests offengelegten Zugangsdaten; behandeln Sie Trigger-Skripte/Shell-Verlauf als vertraulich

Prüfprotokoll

Datenaufbereitungsmanifeste, Prüfpunktprotokolle und Archivmanifeste dienen als Nachweis für die Einhaltung von Vorschriften.

[[10-2-validation-and-testing]]
== 10.2 Validierung und Testen

Die Validierung bestätigt, dass das konfigurierbare Verhalten der Pipeline in Bezug auf Routing, Fehlerbehandlung, Datenmobilität und die Erkennung mehrerer Dateien zuverlässig funktioniert. Jeder Validierungstestbereich wurde in einer repräsentativen Umgebung mit realen Airflow DAG Triggern ausgeführt, wobei die Protokollausgaben und Speichermanifeste auf Korrektheit überprüft wurden.

[[10-2-1-functional-routing-validation]]
=== 10.2.1 Validierung des funktionalen Routings

Dieser Testbereich validiert das durchgängige Daten- und Artefaktrouting, wenn enable_xcp=true.

  • Ziel: Sicherstellen, dass Datenaufbereitung, XCP-Mobilität, Modelltraining, Feinabstimmung und Inferenz konsistent das ausgewählte XCP-Ziel verwenden (s3 oder lustrefs).

  • Testverfahren: DAG-Läufe wurden mit xcp_copy_destination="s3" und xcp_copy_destination="lustrefs" ausgelöst. XCom-Ausgaben, effective-config-Protokolle und Speicherorte wurden überprüft.

  • Validierungsergebnis:

    • In data_prep wurden formatierte tabellarische Aufteilungen und Textdateien auf der ONTAP NAS Prepared-Data-Ebene unter <xcp_prefix>/formatted/<run_stamp>/data/ bereitgestellt.

    • In xcp_copy diesem Fall wurde der vorbereitete Datensatz an das gewählte XCP Ziel für die nachfolgenden Modellschritte übertragen.

    • In model_training wurden Modelleingaben aus dem XCP Ziel geladen, und Basisartefakte (regression_model.bin, text_vectorizer.bin, text_classifier.bin, train_metrics.json) wurden zurück in <xcp_prefix>/formatted/<run_stamp>/artifacts/ veröffentlicht.

    • In fine_tuning wurden Basisvektorisierungs-/Klassifizierungsartefakte aus dem XCP Ziel materialisiert, inkrementell optimiert und als text_classifier_tuned.bin und fine_tune_metrics.json zurück veröffentlicht.

    • In inferencing wurden der optimierte Textklassifikator sowie das Basisregressionsmodell und der Vektorisierer aus dem XCP-Ziel materialisiert, um Vorhersagen zu generieren.

[[10-2-2-local-fallback-and-non-xcp-execution-validation]]
=== 10.2.2 Validierung der lokalen Fallback- und Nicht-XCP-Ausführung

Dieser Testbereich validiert das Pipeline-Verhalten, wenn die XCP Datenmobilität deaktiviert ist (enable_xcp=false).

  • Ziel: Sicherstellen, dass die Pipeline reibungslos mit direkten lokalen Pfaden für vorbereitete Daten funktioniert, ohne dass eine SSH-Verbindung, Remote XCP Hosts oder XCP Anmeldeinformationsprofile erforderlich sind.

  • Testverfahren: Ausgelöste Pipeline-Ausführungen mit enable_xcp=false und Standardpfaden für S3/lokal.

  • Validierungsergebnis:

    • XCP Preflight und Kopieraufgaben wurden sicher umgangen.

    • model_training, fine_tuning und inferencing lesen direkt aus lokalen Verzeichnissen mit aufbereiteten Daten und lokal veröffentlichten Artefakten.

    • Es wurde überprüft, dass keine Fehler bei der Auflösung von XCP S3-Anmeldeinformationen oder SSH-Preflight-Fehler auftraten, als XCP deaktiviert war.

[[10-2-3-performance-and-tier-comparison-ontap-s3-vs-lustrefs]]
=== 10.2.3 Leistungs- und Tiervergleich (ONTAP S3 vs. LustreFS)

Dieser Testbereich evaluiert die E/A-Latenz, den Discovery-Overhead und den Trainingsdurchsatz zwischen ONTAP S3 Objektspeicher und LustreFS Paralleldateisystem Ebenen.

  • Zielsetzung: Quantifizierung der Leistungsmerkmale der E-Serie mit LustreFS im Vergleich zu ONTAP AFF/AFX mit aktiven ONTAP S3 Trainingsebenen.

  • Testverfahren: Gemessen wurden die Dateierkennungszeit, die Latenz beim Laden des Trainingsdatensatzes und die Dauer der Veröffentlichung/Materialisierung von Artefakten bei identischen Datensatzgrößen (14,400+ Zeilen, Text-/Tabelleneingaben aus mehreren Dateien).

  • Validierungsergebnis:

    • LustreFS Tier: Nachweislich geringerer Aufwand bei der Dateierkennung und schnellere Latenz bei Lesezugriffen mit wahlfreiem Zugriff während des Modelltrainings, wodurch es sich ideal für GPU-intensive parallele Trainingsworkloads mit hoher Dateianzahl eignet.

    • ONTAP S3 Tier: Bietet hohen Durchsatz bei einfacherer Verwaltung mehrerer Protokolle und ist somit optimal für kostenbewussten aktiven Speicher mit elastischem Zugriff geeignet, ohne dass Client-seitig Dateisystem-Mounts erforderlich sind.

[[10-2-4-failure-recovery-and-training-checkpoint-validation]]
=== 10.2.4 Validierung von Wiederherstellung nach Ausfällen und Schulungs-Checkpoints

Dieser Testbereich validiert das Checkpoint-Resume-System mit dem Geltungsbereich model_training.

  • Ziel: Es ist sicherzustellen, dass die Pipeline-Wiederherstellung zuvor erfolgreiche Trainingsläufe korrekt erkennt und redundante Berechnungen überspringt, während die Integrität der Artefakte erhalten bleibt.

  • Testverfahren:

    1. Pipeline mit checkpoint_enabled=true und checkpoint_store="formatted_s3" ausgeführt.

    2. Simulierter Aufgabenfehler oder erneute Ausführung mit training_checkpoint_reuse_mode="resume_if_exists".

    3. Getestete verify_only und off Wiederverwendungsmodi.

  • Validierungsergebnis:

    • Wenn resume_if_exists ein gültiger Checkpoint JSON + alle Kernartefakte in S3/LustreFS vorhanden waren, wurde model_training sofort mit der Entscheidung RESUMED_FROM_CHECKPOINT beendet, unter Protokollierung [checkpoint] resume_summary: decision=RESUMED_FROM_CHECKPOINT.

    • Nachgelagert fine_tuning und inferencing wurden die verifizierten Checkpoint-Artefakte erfolgreich materialisiert.

    • Wenn verify_only dies festgelegt war, validierte der Guard die Existenz des Artefakts, ohne das Training zu überspringen.

[[10-2-5-scalability-and-multi-file-dataset-validation]]
=== 10.2.5 Skalierbarkeit und Validierung von Datensätzen mit mehreren Dateien

Dieser Testbereich validiert die Skalierbarkeit über große tabellarische und Textdatensätze mit mehreren Dateien hinweg.

  • Ziel: Bestätigung der automatischen Datensatzerkennung, der Ausführung der Spark-Transformations-Engine und der Unterstützung des Lakehouse-Tabellenformats (delta und iceberg).

  • Testverfahren:

    1. Die Aufnahme und Aufbereitung von Dutzenden von CSV/Parquet-Dateien unter dem StorageGRID Rohpräfix (s3_raw_prefix wurde durchgeführt.

    2. Getestet wurde die explizite Dateiauswahl mit s3_tabular_object_keys im Vergleich zur automatischen Erkennung aller Dateien (sample_count=0).

    3. Vorbereitung mit PySpark mit table_format="delta" und table_format="iceberg" ausgeführt.

  • Validierungsergebnis:

    • Spark distributed preparation hat große, mehrteilige tabellarische Datensätze erfolgreich eingelesen, gefiltert, aufgeteilt und formatiert.

    • Die automatische Erkennung identifizierte präzise alle gültigen tabellarischen CSV/Parquet-Objekte und ignorierte dabei nicht tabellarische Artefakte.

    • Sowohl die Tabellenformate Delta Lake als auch Iceberg wurden korrekt erstellt und unter tables/ registriert, wobei das nachgelagerte Modelltraining die formatierten Aufteilungen erkannte und las.

[[10-2-6-example-customer-evaluation-workflow-sizing-assumptions-and-validation-metrics]]
=== 10.2.6 Beispielhafter Workflow zur Kundenbewertung, Dimensionierungsannahmen und Validierungsmetriken

Dieser Workflow unterstützt Kunden bei der Bewertung, ob das Design ihren Anforderungen an die Reife ihrer KI-Pipeline, die Datenhoheit und die Leistungsziele entspricht. Es wird mit einem repräsentativen Datensatz und einem Pipeline-Lauf begonnen, anschließend werden Datenvolumen, Dateianzahl, Modellkomplexität und Anzahl paralleler Läufe erst erhöht, nachdem jedes Akzeptanzkriterium erfüllt ist. Die Ergebnisse werden run_stamp protokolliert, damit Vergleiche zwischen ONTAP S3 und LustreFS dieselben Eingabedaten und dieselbe Konfiguration verwenden.

Bewertungsschritt Beispielhafter Arbeitsablauf Dimensionierungsannahme / Entscheidung Validierungsmetriken und Akzeptanznachweise

1. Eine Ausgangsbasis festlegen

Der Python-Vorbereitungspfad wird mit enable_xcp=false einer begrenzten Stichprobe ausgeführt.

Die Referenzvalidierungsumgebung aus Abschnitt 7.1.1 dient als anfängliche funktionale Basislinie.

Erfolgreicher DAG-Abschluss; Anzahl der Eingabezeilen und Ausgabe-Splits; Modellmetriken; Aufgabendauer; CPU-, Speicher- und lokale Festplattenauslastung.

2. Datenhoheit validieren

Rohdaten, aufbereitete Daten, aktive Trainingsdaten und Archive werden in genehmigten Speicherendpunkten und Regionen aufbewahrt. Anmeldeinformationen und Aufbewahrungsrichtlinien gelten für jede Ebene.

Die zulässigen Speicherorte, Zugriffsrollen, Verschlüsselungsanforderungen und die Aufbewahrungsrichtlinie sollten vor dem Verschieben von Daten festgelegt werden.

Endpunkt, Bucket, Präfix und Region in der effektiven Konfiguration und in den Manifesten erfasst; Überprüfung des Zugriffs nach dem Least-Privilege-Prinzip; Nachweis der Archivierungs- und Löschrichtlinien.

3. Validierung der Datenmobilität

XCP wird aktiviert und derselbe vorbereitete Lauf nach ONTAP S3 kopiert, anschließend wird der Vorgang für LustreFS wiederholt.

10-GbE-Konnektivität und ausreichende Zielkapazität für den vorbereiteten Lauf, die Artefakte, den Arbeitsbereich und gleichzeitige Läufe müssen sichergestellt sein.

XCP Abschlussstatus; Anzahl kopierter Bytes und Dateien; Kopierdauer und Durchsatz; Anzahl der Quell-/Zieldateien und Vergleich von Prüfsumme oder Manifest; erfolgreicher Vorabcheck.

4. Überprüfung der Eignung des Trainingsniveaus

Training, Feinabstimmung und Inferenz erfolgen für jedes ausgewählte Ziel mit denselben Datensätzen und Modelleinstellungen.

ONTAP S3 eignet sich für objektbasierte Workflows; E-Series mit LustreFS eignet sich, wenn paralleles Trainings-I/O oder eine hohe Anzahl von Dateien dies rechtfertigen.

Datensatzerkennung und Ladezeit; Dauer von Training, Feinabstimmung und Inferenz; Dauer der Veröffentlichung/Materialisierung von Artefakten; CPU-/GPU-Auslastung, sofern zutreffend; Konsistenz der Modellqualität.

5. Skalierung und Wiederherstellung validieren

Erhöhung `sample_count`für alle Zeilen sowie der Dateianzahl und der gleichzeitigen Ausführungen, anschließend Test der Wiederverwendung von Prüfpunkten und der Archivierung.

Kapazität für die Speicherung laufbezogener Datensätze und Artefakte sowie Wachstumsspielraum dimensionieren; CPU- und Speicherkapazität für Spark und gleichzeitige Airflow-Aufgaben dimensionieren.

End-to-End-Verstrichene Zeit; Erfolgsquote bei erfolgreichen Ausführungen; Warteschlangenzeit; Entscheidung zur Wiederaufnahme des Checkpoints und verstrichene Zeit; Vollständigkeit des Archivs; Speicherwachstum pro Durchlauf; Erreichen des Recovery Time Objective (RTO).

Vor Beginn der Evaluierung sollten Kunden quantitative Zielvorgaben für die End-to-End-Laufzeit, den XCP-Durchsatz, die Ladezeit der Trainingsdaten, die maximale Anzahl gleichzeitiger Ausführungen, die Wiederherstellungszeit und die Speicheraufbewahrung definieren. Die gemessene Basislinie und jeder skalierte Test sollten mit diesen Zielvorgaben verglichen werden, um festzustellen, ob die Architektur die beabsichtigte Workload und die betrieblichen Anforderungen erfüllt.