- Überblick
- Anforderungen
- Bereitstellungsvorlagen
- Anleitung: Vorbereiten der Installation
- Anleitung: Vorbereiten der Installation
- Schritt 1: Konfigurieren der OCI-konformen Registrierung für Offline-Installationen
- Schritt 2: Konfigurieren des externen Objektspeichers
- Schritt 3: Konfigurieren eines High Availability Add-ons
- Schritt 4: Konfigurieren der SQL-Datenbanken
- Schritt 5: Konfigurieren des Lastausgleichs
- Schritt 6: Konfigurieren des DNS
- Schritt 7: Konfigurieren der Datenträger
- Schritt 8: Konfigurieren der Einstellungen auf Kernel- und Betriebssystemebene
- Schritt 9: Konfigurieren der Knotenports
- Schritt 10: Anwenden verschiedener Einstellungen
- Schritt 12: Validieren und Installieren der erforderlichen RPM-Pakete
- Cluster_config.json-Beispiel
- Allgemeine Konfiguration
- Profilkonfiguration
- Zertifikatkonfiguration
- Datenbankkonfiguration
- Konfiguration des externen Objektspeichers
- Vorsignierte URL-Konfiguration
- ArgoCD-Konfiguration
- Externe OCI-konforme Registrierungskonfiguration
- Disaster Recovery: Aktiv/Passiv- und Aktiv/Aktiv-Konfigurationen
- Konfiguration des High Availability Add-ons
- Spezifische Orchestrator-Konfiguration
- Insights-spezifische Konfiguration
- Process Mining-spezifische Konfiguration
- Spezifische Konfiguration für Document Understanding
- Spezifische Konfiguration für Automation Suite Robots
- AI Center-spezifische Konfiguration
- Konfiguration der Überwachung
- Optional: Konfigurieren des Proxyservers
- Optional: Aktivieren der Widerstandsfähigkeit gegen zonale Ausfälle in einem HA-fähigen Produktionscluster mit mehreren Knoten
- Optional: Übergeben einer benutzerdefinierten resolv.conf-Datei
- Optional: Erhöhen der Fehlertoleranz
- Hinzufügen eines dedizierten Agent-Knotens mit GPU-Unterstützung
- Hinzufügen eines dedizierten Agent-Knotens für Task Mining
- Verbinden einer Task Mining-Anwendung
- Hinzufügen eines dedizierten Agentenknotens für Automation Suite-Roboter
- Schritt 15: Konfigurieren der temporären Docker-Registrierung für Offline-Installationen
- Schritt 16: Validieren der Voraussetzungen für die Installation
- Manuell: Durchführen der Installation
- Nach der Installation
- Clusterverwaltung
- Verwalten von Produkten
- Erste Schritte mit dem Clusterverwaltungsportal
- Migrieren von Objectstore von persistentem Volume zu Raw-Festplatten
- Migrieren vom clusterinternen zum externen High Availability Add-on
- Migrieren von Daten zwischen Objectstores
- Clusterinterner Objectstore zu einem externen Objectstore migrieren
- Migrieren zu einer externen OCI-konformen Registrierung
- Manueller Wechsel zum sekundären Cluster in einem Aktiv-/Passiv-Setup
- Disaster Recovery: Durchführen von Vorgängen nach der Installation
- Umwandlung einer bestehenden Installation in eine Multi-Site-Einrichtung
- Richtlinien zum Upgrade einer Aktiv/Passiv- oder Aktiv/Aktiv-Bereitstellung
- Leitlinien zum Sichern und Wiederherstellen einer Aktiv-/Passiv- oder Aktiv/Aktiv-Bereitstellung
- Skalieren einer Bereitstellung mit einem einzelnen Knoten (Auswertung) zu einer Bereitstellung mit mehreren Knoten (HA).
- Überwachung und Warnungen
- Migration und Upgrade
- Migrieren von eigenständigen Produkten zur Automation Suite
- Schritt 1: Wiederherstellen der eigenständigen Produktdatenbank
- Schritt 2: Aktualisieren des Schemas der wiederhergestellten Produktdatenbank
- Schritt 3: Verschieben der Identitätsorganisationsdaten von der eigenständigen Bereitstellung in die Automation Suite
- Schritt 4: Sichern der Plattformdatenbank in der Automation Suite
- Schritt 5: Zusammenführen von Organisationen in der Automation Suite
- Schritt 6: Aktualisieren der migrierten Produktverbindungszeichenfolgen
- Schritt 7: Migrieren des eigenständigen Orchestrator
- Schritt 8: Migrieren von eigenständigen Insights
- Schritt 9: Löschen des Standardmandanten
- Durchführen der Migration eines einzelnen Mandanten
- Migrieren zwischen Automation Suite-Clustern
- Aktualisieren der Automation Suite
- Herunterladen der Installationspakete und Übertragen aller Dateien auf den ersten Serverknoten
- Abrufen der zuletzt angewendeten Konfiguration aus dem Cluster
- Aktualisieren der Clusterkonfiguration
- Konfigurieren der OCI-konformen Registrierung für Offline-Installationen
- Ausführen des Upgrades
- Durchführen von Vorgängen nach dem Upgrade
- Produktspezifische Konfiguration
- Konfigurieren von Orchestrator-Parametern
- Konfigurieren von AppSettings
- Konfigurieren der maximalen Anforderungsgröße
- Überschreiben der Speicherkonfiguration auf Clusterebene
- Konfigurieren von NLog
- Speichern von Roboterprotokollen in Elasticsearch
- Konfigurieren von Anmeldeinformationsspeichern
- Konfigurieren der Verwendung von einem Verschlüsselungsschlüssel pro Mandant
- Bereinigen der Orchestrator-Datenbank
- Best Practices und Wartung
- Fehlersuche und ‑behebung
- Fehlerbehebung bei Diensten während der Installation
- Deinstallieren des Clusters
- Löschen von Offline-Artefakten für mehr Speicherplatz
- So löschen Sie Redis-Daten
- So können Sie die Istio-Protokollierung aktivieren
- So werden Protokolle manuell bereinigt
- So löschen Sie alte Protokolle, die im sf-logs-Bucket gespeichert sind
- So deaktivieren Sie Streaming-Protokolle für das AI Center
- Fehlerbehebung bei fehlgeschlagenen Automation Suite-Installationen
- So löschen Sie Bilder aus dem alten Installationsprogramm nach dem Upgrade
- Deaktivieren von TX-Prüfsummen-Offloading
- So legen Sie die ArgoCD-Protokollebene manuell auf Info fest
- So erweitern Sie den AI Center-Speicher
- So wird der codierte pull_secret_value für externe Registrierungen generiert
- Umgang mit schwachen Verschlüsselungen in TLS 1.2
- So überprüfen Sie die TLS-Version
- So arbeiten Sie mit Zertifikaten
- So planen Sie die Ceph-Sicherung und Wiederherstellung von Daten
- So löschen Sie ungenutzte Docker-Images aus Registrierungs-Pods
- Es kann keine Offlineinstallation auf RHEL 8.4 OS ausgeführt werden.
- Fehler beim Herunterladen des Pakets
- Die Offlineinstallation schlägt aufgrund fehlender binärer Dateien fehl
- Zertifikatproblem bei der Offlineinstallation
- Validierungsfehler bei der SQL-Verbindungszeichenfolge
- Voraussetzungsprüfung für das Selinux-iscsid-Modul schlägt fehl
- Azure-Datenträger nicht als SSD markiert
- Fehler nach der Zertifikatsaktualisierung
- Virenschutz verursacht Probleme bei der Installation
- Automation Suite funktioniert nach Betriebssystem-Upgrade nicht
- Bei der Automation Suite muss „backlog_wait_time“ auf 0 gesetzt werden.
- Volume nicht bereitstellbar, da es nicht für Workloads bereit ist
- Fehler bei der Protokollsammlung des Supportpakets
- Die temporäre Registrierungsinstallation schlägt unter RHEL 8.9 fehl
- Datenverlust bei der Neuinstallation oder Aktualisierung von Insights nach dem Automation Suite-Upgrade
- Zugriff auf Automation Hub nach Upgrade auf Automation Suite 2024.10.0 nicht mehr möglich
- Das Upgrade eines einzelnen Knotens schlägt in der Fabric-Phase fehl
- Upgrade schlägt aufgrund eines fehlerhaften Ceph . fehl
- Rke2 wird aufgrund von Platzproblemen nicht gestartet
- Datenträger kann nicht verbunden werden und verbleibt im Status der „Attach/Detach“-Schleife
- Upgrade schlägt aufgrund von klassischen Objekten in der Orchestrator-Datenbank fehl
- Ceph-Cluster in beeinträchtigtem Status nach parallelem Upgrade
- Fehlerhafte Insights-Komponente verursacht Fehlschlag der Migration
- Dienst-Upgrade schlägt für Apps fehl
- Timeouts beim direkten Upgrade
- Docker-Registrierungsmigration bleibt in PVC-Löschphase hängen
- AI Center-Bereitstellungsfehler nach Upgrade auf 2023.10 oder höher
- Upgrade schlägt in Offline-Umgebungen fehl
- SQL-Validierung schlägt während des Upgrades fehl
- Snapshot-controller-crds Pod im Status CrashLoopBackOff nach dem Upgrade
- Upgrade schlägt aufgrund überschriebener Insights-PVC-Größen fehl
- Fehler beim Upgrade auf Automation Suite 2024.10.1
- Upgrade schlägt aufgrund eines Velero-Migrationsproblems fehl
- Fehler beim Hoch- oder Herunterladen von Daten im Objektspeicher
- Die Größenänderung eines PVC bewirkt keine Korrektur von Ceph
- Fehler beim Ändern der Größe von objectstore PVC
- Rook Ceph oder Looker-Pod hängen im Init-Status fest
- Fehler beim Anhängen eines StatefulSet-Volumes
- Fehler beim Erstellen persistenter Volumes
- Festlegen eines Timeout-Intervalls für die Verwaltungsportale
- Die Authentifizierung funktioniert nach der Migration nicht
- kinit: KDC kann für Realm <AD Domain> beim Abrufen der ersten Anmeldeinformationen nicht gefunden werden
- Kinit: Keytab enthält keine geeigneten Schlüssel für *** beim Abrufen der ersten Anmeldeinformationen
- GSSAPI-Vorgang aufgrund eines ungültigen Statuscodes fehlgeschlagen
- Alarm für fehlgeschlagenen Kerberos-tgt-update-Auftrag erhalten
- SSPI-Anbieter: Server in Kerberos-Datenbank nicht gefunden
- Anmeldung eines AD-Benutzers aufgrund eines deaktivierten Kontos fehlgeschlagen
- ArgoCD-Anmeldung fehlgeschlagen
- Aktualisieren Sie die zugrunde liegenden Verzeichnisverbindungen
- Der Roboter kann keine Verbindung mit einer Automation Suite-Orchestrator-Instanz herstellen
- Teilweiser Fehler beim Wiederherstellen der Sicherung in der Automation Suite 2024.10.0
- Fehler beim Abrufen des Sandbox-Abbilds
- Pods werden nicht in der ArgoCD-Benutzeroberfläche angezeigt
- Redis-Testfehler
- RKE2-Server kann nicht gestartet werden
- Secret nicht im UiPath-Namespace gefunden
- ArgoCD wechselt nach der ersten Installation in den Status „In Bearbeitung“.
- MongoDB-Pods in „CrashLoopBackOff“ oder ausstehende PVC-Bereitstellung nach Löschung
- Pods stecken in Init:0/X
- Fehlende Ceph-rook-Metriken in Überwachungs-Dashboards
- Diskrepanz bei gemeldeten Fehlern bei diagnostischen Zustandsprüfungen
- Kein normales Upstream-Problem
- Document Understanding erscheint nicht auf der linken Leiste der Automation Suite
- Fehlerstatus beim Erstellen einer Datenbeschriftungssitzung
- Fehlerstatus beim Versuch, eine ML-Fähigkeit bereitzustellen
- Migrationsauftrag schlägt in ArgoCD fehl
- Die Handschrifterkennung mit dem Intelligent Form Extractor funktioniert nicht oder arbeitet zu langsam
- Ausführen von Hochverfügbarkeit mit Process Mining
- Die Process Mining-Datenaufnahme ist bei der Anmeldung über Kerberos fehlgeschlagen
- Nach Disaster Recovery funktioniert Dapr für Process Mining nicht mehr ordnungsgemäß
- Verbindung mit der Datenbank „AutomationSuite_ProcessMining_Lager“ über eine Verbindungszeichenfolge im pyodbc-Format nicht möglich
- Die Airflow-Installation schlägt mit „sqlaldemy.exc.ArgumentError“ fehl: URL konnte nicht analysiert werden rfc1738 aus Zeichenfolge „
- So fügen Sie eine IP-Tabellenregel hinzu, um den SQL Server-Port 1433 zu verwenden
- Dem Automation Suite-Zertifikat des Servers, auf dem CData Sync ausgeführt wird, wird nicht vertraut
- Ausführen des Diagnosetools
- Verwenden des Automation Suite-Supportpakets
- Erkunden von Protokollen
- Untersuchen der zusammengefassten Telemetrie

Automation Suite unter Linux – Installationsanleitung
Speicherwarnungen
Diese Warnung weist darauf hin, dass die Datenträgernutzung auf dem Kubernetes-Knoten sehr hoch ist.
Wenn diese Warnung ausgelöst wird, versuchen Sie herauszufinden, welcher Pod mehr Datenträger verbraucht:
-
Bestätigen Sie mit dem folgenden Befehl, ob sich der Knoten unter
DiskPressure
befindet:kubectl describe node <node-name>
kubectl describe node <node-name>Identifizieren Sie für die BedingungDiskPressure
in der Ausgabe. -
Überprüfen Sie die Speicherplatznutzung auf dem betroffenen Knoten:
df -h
df -hHier wird die Datenträgernutzung auf allen bereitgestellten Dateisystemen angezeigt. Ermitteln Sie die hohe Nutzung.
-
Wenn der Datenträger voll und die Bereinigung unzureichend ist, sollten Sie eine Größenänderung des Datenträgers für den Knoten in Betracht ziehen ( insbesondere in Cloud-Umgebungen wie AWS oder GCP). Dieser Prozess kann je nach Ihrer Infrastruktur eine Erweiterung der Volumes erfordern.
Diese Warnung weist darauf hin, dass die Speicherauslastung auf dem Kubernetes-Knoten sehr hoch ist.
MemoryPressure
tritt auf, wenn ein Kubernetes-Clusterknoten nicht mehr über den Arbeitsspeicher verfügt, was durch einen Speicherverlust in einer Anwendung verursacht werden kann. Dieser Vorfalltyp erfordert sofortige Aufmerksamkeit, um Ausfallzeiten zu vermeiden und das ordnungsgemäße Funktionieren des Kubernetes-Clusters sicherzustellen.
Wenn diese Warnung ausgelöst wird, versuchen Sie, den Pod auf dem Knoten zu identifizieren, der mehr Speicher verbraucht, indem Sie die folgenden Schritte ausführen:
-
Rufen Sie die CPU- und Speicherstatistiken der Knoten ab:
kubectl top node
kubectl top node -
Rufen Sie die Pods ab, die auf dem Knoten ausgeführt werden:
kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=${NODE_NAME}
kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=${NODE_NAME} -
Überprüfen Sie die Speichernutzung für Pods in einem Namespace mit:
kubectl top pod --namespace <namespace> kubectl logs -f <pod-name> -n <ns>
kubectl top pod --namespace <namespace> kubectl logs -f <pod-name> -n <ns>
Wenn Sie einen Pod mit hoher Speicherauslastung identifizieren können, überprüfen Sie die Protokolle des Pods und suchen Sie nach Speicherverlustfehlern.
Um das Problem zu beheben, erhöhen Sie nach Möglichkeit die Speicherspezifikation für die Knoten.
Wenn das Problem weiterhin besteht, generieren Sie das Supportpaket und wenden Sie sich an den UiPath®-Support.
Bei Warnend: Der verfügbare Speicherplatz beträgt weniger als 30 % und wird wahrscheinlich innerhalb von vier Tagen ausgefüllt.
Bei Kritisch: Der verfügbare Speicherplatz ist weniger als 10 %.
Bei allen Diensten, bei denen der Speicherplatz knapp wird, kann es schwierig werden, die Daten wiederherzustellen. Daher sollten die Volumes verkleinert werden, bevor der verfügbare Speicherplatz 0 % erreicht.
Anweisungen finden Sie unter Konfigurieren des Clusters.
Weitere Informationen und Anweisungen zu Prometheus-spezifischen Warnungen finden Sie unter PrometheusStorageUsage .
Das Dateisystem auf einem bestimmten Knoten füllt sich.
Wenn diese Warnung ausgelöst wird, sollten Sie die folgenden Schritte beachten:
-
Bestätigen Sie mit dem folgenden Befehl, ob sich der Knoten unter
DiskPressure
befindet:kubectl describe node <node-name>
kubectl describe node <node-name>Identifizieren Sie für die BedingungDiskPressure
in der Ausgabe.
-
Löschen Sie die Protokolle und temporären Dateien. Suchen Sie nach großen Protokolldateien in
/var/log/
und bereinigen Sie diese, wenn möglich.
-
Überprüfen Sie die Speicherplatznutzung auf dem betroffenen Knoten:
df -h
df -hHier wird die Datenträgernutzung auf allen bereitgestellten Dateisystemen angezeigt. Ermitteln Sie die hohe Nutzung.
-
Wenn der Datenträger voll und die Bereinigung unzureichend ist, sollten Sie eine Größenänderung des Datenträgers für den Knoten in Betracht ziehen ( insbesondere in Cloud-Umgebungen wie AWS oder GCP). Dieser Prozess kann je nach Ihrer Infrastruktur eine Erweiterung der Volumes erfordern.
Das Dateisystem auf einem bestimmten Knoten füllt sich. Stellen Sie mehr Speicherplatz zur Verfügung, indem Sie eine Festplatte hinzufügen oder nicht verwendete Datenträger einhängen.
Das Dateisystem auf einem bestimmten Knoten füllt sich. Stellen Sie mehr Speicherplatz zur Verfügung, indem Sie eine Festplatte hinzufügen oder nicht verwendete Datenträger einhängen.
Das Dateisystem auf einem bestimmten Knoten füllt sich. Stellen Sie mehr Speicherplatz zur Verfügung, indem Sie eine Festplatte hinzufügen oder nicht verwendete Datenträger einhängen.
Diese Fehler weisen darauf hin, dass der Netzwerktreiber eine hohe Anzahl von Fehlern meldet. Dies kann durch physische Hardwarefehler oder Fehlkonfiguration im physischen Netzwerk verursacht werden. Dieses Problem betrifft das Betriebssystem und wird nicht durch die UiPath®-Anwendung gesteuert.
/proc/net/dev
ausgelöst, den der Linux-Kernel bereitstellt.
Wenden Sie sich an Ihren Netzwerkadministrator und das Team, das die physische Infrastruktur verwaltet.
Diese Fehler weisen darauf hin, dass der Netzwerktreiber eine hohe Anzahl von Fehlern meldet. Dies kann durch physische Hardwarefehler oder Fehlkonfiguration im physischen Netzwerk verursacht werden. Dieses Problem betrifft das Betriebssystem und wird nicht durch die UiPath®-Anwendung gesteuert.
/proc/net/dev
ausgelöst, den der Linux-Kernel bereitstellt.
Wenden Sie sich an Ihren Netzwerkadministrator und das Team, das die physische Infrastruktur verwaltet.
Diese Warnung gibt an, dass sich der Ceph-Speichercluster seit mehr als 10 Minuten im Fehlerzustand befindet.
rook-ceph-mgr
-Auftrag für eine inakzeptable Zeit im Fehlerstatus befindet. Suchen Sie nach anderen Warnungen, die möglicherweise vor dieser Warnung ausgelöst wurden, und beheben Sie diese zuerst.
kubectl describe cephcluster -n rook-ceph
kubectl describe cephcluster -n rook-ceph
Diese Warnung gibt an, dass das Quorum des Speicherclusters niedrig ist.
Mehrere Mons arbeiten zusammen, um Redundanz bereitzustellen. Dies ist möglich, da jeder eine Kopie der Metadaten behält. Der Cluster wird mit 3 Mons bereitgestellt und erfordert, dass 2 oder mehr Mons aktiv sind, damit das Quorum und die Speichervorgänge ausgeführt werden können. Wenn das Quorum verloren geht, ist der Zugriff auf die Daten gefährdet.
Wenn diese Warnung ausgelöst wird, überprüfen Sie, ob sich OSDs im Beendigungsstatus befinden. Wenn das zutrifft, erzwingen Sie die Löschung dieser Pods und warten Sie einige Zeit, bis der Operator abgestimmt ist. Wenn das Problem weiterhin besteht, wenden Sie sich an den UiPath®-Support.
Diese Warnung weist darauf hin, dass der Ceph Manager aus der Prometheus-Zielerkennung verschwunden ist.
Wenn diese Warnung ausgelöst wird, überprüfen und stellen Sie sicher, dass der Ceph Manager-Pod in Betrieb ist und fehlerfrei ist. Wenn der Pod fehlerfrei ist, überprüfen Sie bitte die Protokolle und stellen Sie sicher, dass der Pod in der Lage ist, Prometheus-Metriken auszugeben.
Diese Warnung weist darauf hin, dass ein Knoten, der Ceph-Pods ausführt, ausgefallen ist. Während der Speichervorgang weiterhin funktioniert, da Ceph für den Umgang mit einem Knotenfehler entwickelt wurde, wird empfohlen, das Problem zu beheben, um das Risiko zu minimieren, dass ein anderer Knoten ausfällt und die Speicherfunktionen beeinträchtigt werden.
rook-ceph
ausgeführt werden und sich im neuen Knoten in einem fehlerfreien Zustand befinden.
Sie können den Knotenfehler überprüfen, indem Sie den Knoten mit dem folgenden Befehl beschreiben:
kubectl get nodes
kubectl get nodes
Überprüfen Sie den Knoten, um die Ursache des Problems zu ermitteln, und wenden Sie sich an den UiPath®-Support.
Diese Warnung zeigt an, dass die Nutzung des Ceph-Speicherclusters 75 % überschritten hat und bei 85 % schreibgeschützt ist.
Wenn diese Warnung ausgelöst wird, schaffen Sie Platz in Ceph, indem Sie einige nicht verwendete Datasets in AI Center oder Task Mining löschen, oder erweitern Sie den für Ceph PVC verfügbaren Speicherplatz.
Bevor Sie die PVC-Größe ändern, stellen Sie sicher, dass Sie die Speicheranforderungen erfüllen. Weitere Informationen finden Sie unter Bewerten Ihres Speicherbedarfs.
Diese Warnung zeigt an, dass die Nutzung des Ceph-Speicherclusters 80 % überschritten hat und bei 85 % schreibgeschützt ist.
Wenn diese Warnung ausgelöst wird, schaffen Sie Platz in Ceph, indem Sie einige nicht verwendete Datasets in AI Center oder Task Mining löschen, oder erweitern Sie den für Ceph PVC verfügbaren Speicherplatz.
Bevor Sie die PVC-Größe ändern, stellen Sie sicher, dass Sie die Speicheranforderungen erfüllen. Weitere Informationen finden Sie unter Bewerten Ihres Speicherbedarfs.
Diese Warnung gibt an, dass die Nutzung des Ceph-Speicherclusters 85 % überschritten hat und jetzt schreibgeschützt ist. Geben Sie Speicherplatz frei, oder erweitern Sie den Speichercluster sofort.
Wenn diese Warnung ausgelöst wird, schaffen Sie Platz in Ceph, indem Sie einige nicht verwendete Datasets in AI Center oder Task Mining löschen, oder erweitern Sie den für Ceph PVC verfügbaren Speicherplatz.
Bevor Sie die PVC-Größe ändern, stellen Sie sicher, dass Sie die Speicheranforderungen erfüllen. Weitere Informationen finden Sie unter Bewerten Ihres Speicherbedarfs.
Wenn der Schweregrad der Warnung Kritisch ist, ist der verfügbare Speicherplatz kleiner als 20 %.
Bei allen Diensten, bei denen der Speicherplatz knapp wird, kann es schwierig werden, die Daten wiederherzustellen. Daher sollten die Volumes verkleinert werden, bevor der verfügbare Speicherplatz 10 % erreicht. Siehe folgende Anweisungen: Konfigurieren des Clusters.
Diese Warnung zeigt an, dass die Nutzung des Ceph-Speicherclusters 75 % überschritten hat und bei 85 % schreibgeschützt ist.
Wenn diese Warnung ausgelöst wird, schaffen Sie Platz in Ceph, indem Sie einige nicht verwendete Datasets in AI Center oder Task Mining löschen, oder erweitern Sie den für Ceph PVC verfügbaren Speicherplatz.
Bevor Sie die PVC-Größe ändern, stellen Sie sicher, dass Sie die Speicheranforderungen erfüllen. Weitere Informationen finden Sie unter Bewerten Ihres Speicherbedarfs.
Diese Warnung zeigt an, dass die Nutzung des Ceph-Speicherclusters 75 % überschritten hat und bei 85 % schreibgeschützt ist.
Wenn diese Warnung ausgelöst wird, schaffen Sie Platz in Ceph, indem Sie einige nicht verwendete Datasets in AI Center oder Task Mining löschen, oder erweitern Sie den für Ceph PVC verfügbaren Speicherplatz.
Bevor Sie die PVC-Größe ändern, stellen Sie sicher, dass Sie die Speicheranforderungen erfüllen. Weitere Informationen finden Sie unter Bewerten Ihres Speicherbedarfs.
Diese Warnung weist darauf hin, dass der Speicher-Daemon in den letzten fünf Minuten mehr als fünfmal neu gestartet wurde.
Wenn diese Warnung ausgelöst wird, führen Sie die folgenden Schritte aus:
-
Überprüfen Sie den Zustand des Ceph-Clusters. Sie müssen
ceph status
in der Ceph-Toolbox ausführen, um die schwebenden OSDs zu identifizieren:Sie können den Pod der Ceph-Tools identifizieren, indem Sie die Pods im Namespace auflisten:kubectl -n rook-ceph exec -it <ceph-tools-pod> -- ceph status
kubectl -n rook-ceph exec -it <ceph-tools-pod> -- ceph statuskubectl -n rook-ceph get pod | grep tools
kubectl -n rook-ceph get pod | grep tools -
Überprüfen Sie die OSD-Protokolle auf den wechselnden OSD-Pod, um Probleme zu identifizieren:
kubectl -n rook-ceph logs <osd-pod>
kubectl -n rook-ceph logs <osd-pod> -
Probleme auf Knotenebene identifizieren:
-
Überprüfen Sie die Ressourcennutzung:
kubectl top node <node-name>
kubectl top node <node-name> -
Überprüfen Sie den Zustand des Datenträgers. Sie müssen eine SSH-Verbindung in den Knoten herstellen und
df -h
unddmesg
ausführen, um Festplattenfehler zu überprüfen.
-
-
Starten Sie den OSD-Pod neu. Wenn das Problem nur vorübergehend ist, müssen Sie den wechselnden OSD-Pod neu starten:
kubectl -n rook-ceph delete pod <osd-pod>
kubectl -n rook-ceph delete pod <osd-pod> -
Stellen Sie sicher, dass es keine Netzwerkkonnektivitätsprobleme zwischen OSDs und Ceph-Monitoren gibt.
-
Markieren Sie bei Bedarf das wechselnde OSD vorübergehend als
out
:ceph osd out <osd-id>
ceph osd out <osd-id> -
Überwachen Sie den Cluster weiterhin, um sicherzustellen, dass das Problem nicht erneut auftritt.
Diese Warnung zeigt an, dass das Host-Datenträgergerät nicht reagiert.
Wenn diese Warnung ausgelöst wird, führen Sie die folgenden Schritte aus:
-
Überprüfen Sie den Status des Ceph-Clusters. Sie müssen den allgemeinen Zustand des Ceph-Clusters bestätigen und weitere Details zum OSD-Status erhalten:
-
Führen Sie den folgenden Befehl innerhalb des Ceph-Toolbox-Pods aus:
kubectl -n rook-ceph exec -it <ceph-tools-pod> -- ceph status
kubectl -n rook-ceph exec -it <ceph-tools-pod> -- ceph status -
Identifizieren Sie den Pod der Ceph-Tools, indem Sie die Pods im Namespace auflisten:
kubectl -n rook-ceph get pod | grep tools
kubectl -n rook-ceph get pod | grep tools
-
-
Überprüfen Sie den OSD-Pod-Status. Sie müssen überprüfen, ob die OSD-Pods ausgeführt werden. Führen Sie den folgenden Befehl aus, um alle OSD-Pod-Status zu überprüfen:
kubectl -n rook-ceph get pods | grep osd
kubectl -n rook-ceph get pods | grep osdWenn sich ein OSD-Pod im StatusCrashLoopBackOff
oderPending
befindet, könnte dies auf ein Problem mit dem OSD-Datenträger oder dem zugrunde liegenden Knoten hinweisen. -
Starten Sie den betroffenen OSD-Pod neu. Wenn sich ein OSD-Pod in einem schlechten Zustand befindet (
CrashLoopBackOff
,Error
usw.), müssen Sie den Pod neu starten, um zu sehen, ob sich das Problem von selbst löst. Kubernetes versucht automatisch, den Pod umzuplanen.kubectl -n rook-ceph delete pod <osd-pod>
kubectl -n rook-ceph delete pod <osd-pod>Der OSD-Pod wird neu gestartet, und wenn es sich um ein vorübergehendes Problem handelt, kann es dadurch behoben werden.
-
Überprüfen Sie die OSD-Protokolle. Wenn der Neustart das Problem nicht behoben hat, überprüfen Sie die OSD-Pod-Protokolle auf weitere Informationen darüber, warum der Datenträger nicht reagiert:
kubectl -n rook-ceph logs <osd-pod>
kubectl -n rook-ceph logs <osd-pod>Suchen Sie nach Fehlern im Zusammenhang mit dem Datenträger oder anderen Problemen (z. B. E/A-Fehler, fehlgeschlagene Bereitstellungen).
-
Identifizieren Sie Probleme auf Knotenebene. Wenn der OSD-Datenträger nicht ordnungsgemäß bereitgestellt oder getrennt wurde, können Sie sich beim betroffenen Knoten anmelden und den Status der Datenträgerbereitstellung überprüfen:
ssh <node> df -h
ssh <node> df -hSuchen Sie nach fehlenden oder nicht bereitgestellten Datenträgern, die Ceph erwartet. Binden Sie den Datenträger ggf. erneut ein oder ersetzen Sie ihn, wenn er fehlgeschlagen ist.
Diese Warnung weist darauf hin, dass der Ceph OSD-Datenträger auf dem Host nicht zugänglich ist.
Wenn diese Warnung ausgelöst wird, führen Sie die folgenden Schritte aus:
-
Überprüfen Sie den Status des Ceph-Clusters. Sie müssen den allgemeinen Zustand des Ceph-Clusters bestätigen und weitere Details zum OSD-Status erhalten:
-
Führen Sie den folgenden Befehl innerhalb des Ceph-Toolbox-Pods aus:
kubectl -n rook-ceph exec -it <ceph-tools-pod> -- ceph status
kubectl -n rook-ceph exec -it <ceph-tools-pod> -- ceph status -
Identifizieren Sie den Pod der Ceph-Tools, indem Sie die Pods im Namespace auflisten:
kubectl -n rook-ceph get pod | grep tools
kubectl -n rook-ceph get pod | grep tools
-
-
Überprüfen Sie den OSD-Pod-Status. Sie müssen überprüfen, ob die OSD-Pods ausgeführt werden. Führen Sie den folgenden Befehl aus, um alle OSD-Pod-Status zu überprüfen:
kubectl -n rook-ceph get pods | grep osd
kubectl -n rook-ceph get pods | grep osdWenn sich ein OSD-Pod im StatusCrashLoopBackOff
oderPending
befindet, könnte dies auf ein Problem mit dem OSD-Datenträger oder dem zugrunde liegenden Knoten hinweisen. -
Starten Sie den betroffenen OSD-Pod neu. Wenn sich ein OSD-Pod in einem schlechten Zustand befindet (
CrashLoopBackOff
,Error
usw.), müssen Sie den Pod neu starten, um zu sehen, ob sich das Problem von selbst löst. Kubernetes versucht automatisch, den Pod umzuplanen.kubectl -n rook-ceph delete pod <osd-pod>
kubectl -n rook-ceph delete pod <osd-pod>Der OSD-Pod wird neu gestartet, und wenn es sich um ein vorübergehendes Problem handelt, kann es dadurch behoben werden.
-
Überprüfen Sie die OSD-Protokolle. Wenn der Neustart das Problem nicht behoben hat, überprüfen Sie die OSD-Pod-Protokolle auf weitere Informationen darüber, warum der Datenträger nicht reagiert:
kubectl -n rook-ceph logs <osd-pod>
kubectl -n rook-ceph logs <osd-pod>Suchen Sie nach Fehlern im Zusammenhang mit dem Datenträger oder anderen Problemen (z. B. E/A-Fehler, fehlgeschlagene Bereitstellungen).
Wenn diese Warnung ausgelöst wird, schaffen Sie Platz in Ceph, indem Sie einige nicht verwendete Datasets in AI Center oder Task Mining löschen, oder erweitern Sie den für Ceph PVC verfügbaren Speicherplatz.
Bevor Sie die PVC-Größe ändern, stellen Sie sicher, dass Sie die Speicheranforderungen erfüllen. Weitere Informationen finden Sie unter Bewerten Ihres Speicherbedarfs.
Diese Warnung gibt an, dass die Nutzung des Ceph-Speicherpools 90 % überschritten hat.
Wenn diese Warnung ausgelöst wird, schaffen Sie Platz in CEPH, indem Sie einige nicht verwendete Datasets in AI Center oder Task Mining löschen, oder erweitern Sie den für Ceph PVC verfügbaren Speicherplatz.
Bevor Sie die PVC-Größe ändern, stellen Sie sicher, dass Sie die Speicheranforderungen erfüllen. Weitere Informationen finden Sie unter Bewerten Ihres Speicherbedarfs.
/var/lib/rancher
kleiner ist als:
- 25 % – Der Schweregrad der Warnung ist kritisch
df -h /var/lib/rancher
verwenden, um den verfügbaren Speicherplatz zu überprüfen. Wenn der Speicherplatz knapp wird, sollten Sie die folgenden Optionen in Betracht ziehen:
-
Löschen Sie die unnötigen Dateien. Im Laufe der Zeit können Protokolldateien, temporäre Dateien, verwaiste Daten und Sicherungen eine beträchtliche Menge an Speicherplatz verbrauchen. Das regelmäßige Bereinigen dieser Dateien kann helfen, den Speicherplatz zu erhalten.
-
Ändern Sie die Partitionsgröße. Wenn Ihr Dateisystem dies unterstützt und auf Ihrer Festplatte ungenutzter Speicherplatz verfügbar ist, können Sie die Partitionsgröße ändern, um mehr Speicherplatz zu erhalten.
-
Fügen Sie mehr Speicherplatz hinzu. Wenn die vorherigen Optionen nicht ausreichen und Ihre Infrastruktur dies zulässt, vergrößern Sie den Datenträger, damit Rancher ordnungsgemäß funktioniert.
-
Überprüfen Sie die Speichernutzung auf ungewöhnlich große Dateien:
find /var/lib/rancher -type f -exec du -h {} + | sort -rh | head -n 10
find /var/lib/rancher -type f -exec du -h {} + | sort -rh | head -n 10 -
Suchen Sie nach Containern, die große Dateien auf die Festplatte schreiben.
/var/lib/kubelet
kleiner ist als:
-
25 % – Der Schweregrad der Warnung ist kritisch
Wenn diese Warnung ausgelöst wird, erhöhen Sie die Größe des Datenträgers.
/var
kleiner ist als:
- 25 % – Der Schweregrad der Warnung ist kritisch
Dies kann durch die Ansammlung von Containersystemprotokollen passieren.
Wenn diese Warnung ausgelöst wird, führen Sie die folgenden Schritte aus:
-
Überprüfen Sie die Speichernutzung:
find /var/ -type f -exec du -h {} + | sort -rh | head -n 10
find /var/ -type f -exec du -h {} + | sort -rh | head -n 10 -
Erhöhen Sie die Größe des Datenträgers.
- kubernetes-system
- KubernetesDiskPressure
- KubernetesMemoryPressure
- KubePersistentVolumeFillingUp
- KubePersistentVolumeErrors
- node-exporter
- NodeFilesystemSpaceFillingUp
- NodeFilesystemAlmostOutOfSpace
- NodeFilesystemFilesFillingUp
- NodeFilesystemAlmostOutOfFiles
- NodeNetworkReceiveErrs
- NodeNetworkTransmitErrs
- ceph.rules, cluster-state-alert.rules
- CephClusterErrorState
- CephMonQuorumAtRisk
- CephMgrIsAbsent
- CephNodeDown
- cluster-utilization-alert.rules
- CephClusterNearFull
- CephClusterCriticallyFull
- CephClusterReadOnly
- osd-alert.rules
- CephOSDCriticallyFull
- CephOSDNearFull
- PersistentVolumeUsageNearFull
- CephOSDlapping
- CephOSDDiskReagiert nicht
- CephOSDDiskUnavailable
- persistent-volume-alert.rules
- PersistentVolumeUsageCritical
- pool-quota.rules
- CephPoolQuotaBytesCriticallyExhausted
- host-disk
- LowDiskForRancherPartition
- LowDiskForKubeletPartition
- LowDiskForVarPartition
- LowDiskForVarLogPartition