Zum Hauptinhalt springen

Troubleshooting

Bandbreiten- und Latenzprobleme sowie HTTP-400-Fehler beim centron S3 Object Storage eingrenzen und beheben.

Bandbreiten- oder Latenzprobleme​

Problem eingrenzen​

  1. Referenzmessung durchführen – idealerweise von einem centron Cloud-Server und vom betroffenen System aus, um Netzwerk- von Storage-Problemen zu trennen:
# Testdatei erzeugen und Upload/Download messen
dd if=/dev/urandom of=test1g.bin bs=1M count=1024
time aws s3 cp test1g.bin s3://mein-bucket/ --endpoint-url https://
time aws s3 cp s3://mein-bucket/test1g.bin ./download.bin --endpoint-url https://s3.internet1.de
  1. Netzwerkpfad prüfen:
ping s3.internet1.de
mtr --report s3.internet1.de     # zeigt Paketverlust/Latenz pro Hop
  1. Statusseite prüfen: status-centron.de

Häufige Ursachen und Lösungen​

SymptomUrsacheLösung
Einzelner Stream langsam, Summe okDurchsatz pro Verbindung begrenztParallelität erhöhen: rclone --transfers 16, AWS CLI max_concurrent_requests, Multipart nutzen
Viele kleine Dateien extrem langsamOverhead pro Request dominiertDateien bündeln (tar/zip) oder Parallelität stark erhöhen (--checkers, --transfers)
Hohe Latenz aus entferntem Netzlanger Netzwerkpfad, PeeringMessung von centron-Server vergleichen; ggf. CDN vorschalten
Schwankender Durchsatz zu Stoßzeitenlokale Leitung/VPN ausgelastetMessung ohne VPN; Bandbreite am Standort prüfen
Uploads großer Dateien brechen abTimeouts bei Single-PUTMultipart-Upload verwenden (machen CLI/SDKs ab Schwellwert automatisch)

AWS-CLI-Tuning (~/.aws/config):

[default]
s3 =
  max_concurrent_requests = 20
  multipart_threshold = 64MB
  multipart_chunksize = 64MB

Lässt sich das Problem reproduzierbar auf die Storage-Seite eingrenzen (auch vom centron-Server aus langsam, Statusseite ohne Meldung), wenden Sie sich mit Messwerten, Zeitpunkt, Bucket und Traceroute an den Support.

HTTP 400 (Bad Request)​

Ein 400 bedeutet: Der Server hat die Anfrage als fehlerhaft abgelehnt. Der Response-Body enthält einen XML-Fehlercode, der die Ursache benennt – zuerst diesen auslesen:

aws s3api get-object --bucket mein-bucket --key test.txt out.txt \
  --endpoint-url https://s3.internet1.de --debug 2>&1 | grep -A5 "<Error>"

Häufige Fehlercodes​

FehlercodeUrsacheLösung
InvalidBucketNameBucket-Name verletzt Namensregeln (Großbuchstaben, Unterstriche, zu kurz/lang)Namensregeln einhalten: 3–63 Zeichen, Kleinbuchstaben/Ziffern/Bindestriche
AuthorizationHeaderMalformedfalsche Region in der SignaturRegion auf setzen (CLI-Config, SDK-Parameter)
RequestTimeTooSkewedSystemuhr weicht > 15 Min. abZeit per NTP synchronisieren (timedatectl, chronyc)
InvalidArgumentungültiger Parameter/Header (z. B. fehlerhafte Metadaten, falsche SSE-C-Header)Request-Parameter prüfen; bei SSE-C alle drei Header inkl. korrekter Key-MD5 senden
EntityTooLarge / EntityTooSmallPart- oder Objektgröße außerhalb der LimitsMultipart-Chunkgröße anpassen (üblich: 5 MB–5 GB pro Part)
KeyTooLongErrorObjekt-Key zu lang (max. 1024 Byte)kürzeren Key verwenden
IncompleteBodyÜbertragung abgebrochen, Content-Length nicht erfülltNetzwerk prüfen, Upload wiederholen
InvalidRequest bei Object-Lock-AufrufenObject Lock am Bucket nicht aktiviertBucket mit Object Lock neu anlegen (nachträglich nicht aktivierbar)
BadDigestMD5/Checksumme stimmt nicht mit Inhalt übereinDatei/Übertragung prüfen, erneut hochladen

Weitere Prüfschritte​

  • Endpoint korrekt? https://s3.internet1.de – Tippfehler oder fehlendes https:// führen zu Signatur-/Verbindungsfehlern.
  • Adressierungsstil: Bei Sonderfällen Path-style erzwingen (SDK-Option forcePathStyle / use_path_style_endpoint).
  • Tool aktuell? Veraltete Clients senden teils inkompatible Signaturen – Update auf aktuelle Version.
  • Nicht unterstützte Action? Manche AWS-Spezialfunktionen existieren hier nicht – siehe Unterstützte S3-Actions.

Bleibt der Fehler unklar: Request-ID aus der Fehlerantwort (<RequestId>) notieren und mit Zeitstempel an den Support geben – damit lässt sich die Anfrage serverseitig nachvollziehen.

Letztes Update am