Bonjour,
Nous rencontrons des erreurs intermittentes sur Object Storage S3 à Paris et cherchons à savoir si nous passons à côté d'une limite, d'un réglage client ou d'une bonne pratique. Un ticket a déjà été ouvert au support OVHcloud ; je poste également ici pour recueillir vos retours d'expérience.
Contexte
- Région :
eu-west-par. - Endpoint :
https://s3.eu-west-par.io.cloud.ovh.net. - Bucket privé, environ 267 000 objets référencés par notre application, principalement des blocs immuables de 4 MiB avec des clés basées sur un hash. Cet inventaire applicatif n'est pas un relevé exhaustif du bucket et de ses versions.
- Notre application utilise le SDK AWS pour Rust pour les PUT/GET, avec vérification complète des données après chaque upload. Nous avons aussi reproduit les erreurs avec curl, en dehors de l'application, via des URL présignées.
- Ces blocs servent à la synchronisation et aux lectures à la demande de disques virtuels : une lecture retardée ou échouée peut bloquer la synchronisation ou l'exécution.
Erreur réellement observée
<Code>ServiceUnavailable</Code>
<Message>Service is unable to handle request.</Message>
Statut HTTP 503. Les réponses capturées contiennent ServiceUnavailable, pas SlowDown.
Reproduction du 7 octobre 2026 — heures UTC
- Entre 09:49:59 et 09:50:02 : le même objet existant a été lu trois fois depuis chacun des chemins suivants : connexion Internet du poste de travail, serveur de production et conteneur de l'application. Résultat : 3 erreurs 503 sur 9 requêtes, avec des réussites et des échecs sur le même objet. Chaque chemin a rencontré au moins un échec.
- Entre 09:53:53 et 09:54:23 : quatre clés proches, depuis le poste de travail et le serveur, avec des GET complets en IPv4 et des GET
Range: bytes=0-0en IPv6. Résultat : 7 erreurs 503 sur 16 requêtes. Même une lecture d'un seul octet pouvait échouer. - Entre 09:55:41 et 09:56:12 : quatre préfixes de hash éloignés (
0,4,8,c). Résultat : 2 erreurs 503 sur 16 requêtes. - Entre 09:56:57 et 09:57:18 : trois tours de GET d'un octet en IPv4, intercalés sur ces quatre préfixes. Résultat : 12 réussites sur 12, avec un temps jusqu'au premier octet d'environ 0,30 à 4,23 secondes.
Ce sont de petits échantillons sélectionnés, pas une estimation du taux d'erreur global. L'adresse IP et le type de GET variaient ensemble dans certains essais ; nous n'en déduisons donc pas qu'IPv4, IPv6, les Range ou un préfixe particulier sont la cause.
Quelques request IDs pour un éventuel rapprochement côté OVHcloud :
- 09:49:59.425 UTC :
tx346a993e11064976a1743-006ac615c6. - 09:50:00.895 UTC :
tx7e1bdbc1cb8843e0a9b27-006ac615c8. - 09:50:01.167 UTC :
txe342465496d2475494555-006ac615c8. - 09:54:11.301 UTC, GET d'un octet en IPv6 :
tx3beed3597e3041b387bd5-006ac616c1.
Débit et vérifications déjà effectuées
Sur une fenêtre d'environ 36 minutes, les compteurs applicatifs du SDK donnaient en moyenne 0,81 GET/s, 0,82 PUT/s et 1,98 opérations de purge/s. Ces compteurs n'incluent pas nécessairement tous les retries HTTP, et une purge peut appeler plusieurs API : ce n'est donc pas une mesure des pics ni un audit complet du trafic du bucket. La limite actuelle de notre application est de quatre uploads simultanés et huit lectures simultanées.
La documentation des limites S3 indique des limites souples de 900 GET/s et 300 PUT/s dans les régions européennes. Les mesures disponibles ne montrent pas que nous approchions ces valeurs ; nous n'avons toutefois pas exclu une limite spécifique au compte ou un pic bref.
- Les erreurs XML 503 ont été reproduites depuis deux connexions Internet indépendantes, avec curl sans SDK.
- Les mêmes objets réussissent lors d'autres tentatives : ce n'est pas un échec permanent de signature ou de permissions.
- Les clés contiennent des hashes ; nous n'utilisons pas un préfixe chronologique croissant.
- Les disques physiques du serveur n'étaient pas saturés lors des mesures. Le serveur avait une activité CPU réelle, mais celle-ci n'explique pas à elle seule la même réponse S3 503 depuis le poste de travail.
- La page publique de statut ne signalait pas d'incident correspondant lors de notre consultation.
Ce que nous cherchons à comprendre
- Avez-vous déjà rencontré ce
503 ServiceUnavailablesur des objets existants, à faible débit, danseu-west-par? - La redistribution des shards ou l'activité de versioning/purge peut-elle provoquer ces erreurs sur des GET, même loin des limites annoncées ? Existe-t-il des métriques permettant de le confirmer ? Nous avons lu la documentation sur le sharding et les performances, mais ne pouvons pas attribuer cet incident à ce mécanisme.
- Y a-t-il un endpoint, une classe de stockage, une limite spécifique au bucket/compte ou un paramètre SDK/HTTP à vérifier en priorité ?
- Quels essais complémentaires permettraient de distinguer un problème de connexion/keepalive, un throttling, un shard en difficulté ou un incident de service ?
- Quelles valeurs de concurrence, de timeout et de retry avec backoff/jitter recommandez-vous pour des blocs immuables de 4 MiB, avec lectures à la demande ?
Nous cherchons d'abord à comprendre et à corriger le problème. Si cette instabilité persiste, nous devrons migrer ces données vers un autre fournisseur, car la fiabilité des lectures conditionne directement la reprise de nos disques.
Merci pour vos pistes ; nous pouvons fournir des logs supplémentaires anonymisés et transmettre les informations propres au bucket directement au support.