Dépannage

Cette page décrit les méthodes de dépannage des erreurs courantes que vous pouvez rencontrer lors de l'utilisation de Cloud Storage.

Consultez le tableau de bord Service Health pour en savoir plus sur les incidents affectant les services Trusted Cloud by S3NS tels que Cloud Storage.Trusted Cloud by S3NS

Journalisation des requêtes brutes

Lorsque vous utilisez des outils tels que gcloud ou les bibliothèques clientes Cloud Storage, la plupart des informations sur les requêtes et les réponses sont gérées par l'outil. Cependant, il est parfois utile d'afficher les détails pour faciliter le dépannage ou lorsque vous publiez des questions sur des forums tels que Stack Overflow. Suivez les instructions ci-dessous pour renvoyer des en-têtes de requête et de réponse pour votre outil :

gcloud storage ls gs://my-bucket/my-object --log-http --verbosity=debug

import logging
import http.client

logging.basicConfig(level=logging.DEBUG)
http.client.HTTPConnection.debuglevel=5

ruby
Google::Apis.logger.level = Logger::DEBUG

Ajouter des en-têtes personnalisés

L'ajout d'en-têtes personnalisés aux requêtes est un outil courant pour le débogage, par exemple pour l'activation des en-têtes de débogage ou pour le suivi d'une requête. L'exemple suivant montre comment définir des en-têtes de requête pour différents outils Cloud Storage :

gcloud storage objects describe gs://my-bucket/my-object --additional-headers=HEADER_NAME=HEADER_VALUE

namespace gcs = google::cloud::storage;
gcs::Client client = ...;
client.AnyFunction(... args ..., gcs::CustomHeader("header-name", "value"));

using Google.Cloud.Storage.V1;

var client = StorageClient.Create();
client.Service.HttpClient.DefaultRequestHeaders.Add("custom-header", "custom-value");

var buckets = client.ListBuckets("my-project-id");
foreach (var bucket in buckets)

{
  Console.WriteLine(bucket.Name);
}

package main

import (
  "context"

  "cloud.google.com/go/storage"
  "github.com/googleapis/gax-go/v2/callctx"
)

func main() {
  ctx := context.Background()

  client, err := storage.NewClient(ctx)
  if err != nil {
    // Handle error.
  }
  ctx = callctx.SetHeaders(ctx, "X-Custom-Header", "value")

  // Use client as usual with the context and the additional headers will be sent.
  _, err = client.Bucket("my-bucket").Attrs(ctx)
  if err != nil {
    // Handle error.
  }
}

import com.google.api.gax.rpc.FixedHeaderProvider;
import com.google.api.gax.rpc.HeaderProvider;
import com.google.cloud.WriteChannel;
import com.google.cloud.storage.BlobInfo;
import com.google.cloud.storage.Storage;
import com.google.cloud.storage.StorageOptions;

import java.io.IOException;
import java.nio.ByteBuffer;
import static java.nio.charset.StandardCharsets.UTF_8;

public class Example {

  public void main(String args[]) throws IOException {
    HeaderProvider headerProvider =
            FixedHeaderProvider.create("custom-header", "custom-value");
    Storage storage = StorageOptions.getDefaultInstance()
            .toBuilder()
            .setHeaderProvider(headerProvider)
            .build().getService();
    String bucketName = "example-bucket";
    String blobName = "test-custom-header";

    // Use client with custom header
    BlobInfo blob = BlobInfo.newBuilder(bucketName, blobName).build();
    byte[] stringBytes;
    try (WriteChannel writer = storage.writer(blob)) {
      stringBytes = "hello world".getBytes(UTF_8);
      writer.write(ByteBuffer.wrap(stringBytes));
    }
  }
}

const storage = new Storage();

storage.interceptors.push({
  request: requestConfig => {
    Object.assign(requestConfig.headers, {
      'X-Custom-Header': 'value',
      });
    return requestConfig;
  },
});

use Google\Cloud\Storage\StorageClient;

$client = new StorageClient([
   'restOptions' => [
       'headers' => [
           'x-foo' => 'bat'
       ]
   ]
]);

$bucket = $client->bucket('my-bucket');

$bucket->info([
   'restOptions' => [
       'headers' => [
           'x-foo' => 'bar'
       ]
   ]
]);

from google.cloud import storage

client = storage.Client(
    extra_headers={
        "x-custom-header": "value"
    }
)

require "google/cloud/storage"

storage = Google::Cloud::Storage.new

storage.add_custom_headers { 'X-Custom-Header'=> 'value' }

Accéder aux buckets avec une configuration CORS

Si vous avez défini une configuration CORS sur votre bucket et que vous constatez que les requêtes entrantes des navigateurs clients échouent, essayez les étapes de dépannage suivantes :

1. Vérifiez la configuration CORS sur le bucket cible. Si vous disposez de plusieurs entrées de configuration CORS, assurez-vous que les valeurs de requête que vous utilisez pour le dépannage sont mappées avec les valeurs d'une seule entrée de configuration CORS.

2. Lorsque vous testez l'envoi d'une requête CORS, vérifiez que vous n'envoyez pas de requête au point de terminaison storage.cloud.google.com, qui n'autorise pas les requêtes CORS. Pour plus d'informations sur les points de terminaison compatibles avec le CORS, consultez la section Compatibilité du CORS avec Cloud Storage.

3. Examinez une requête et sa réponse à l'aide de l'outil de votre choix. Dans un navigateur Chrome, vous pouvez utiliser les outils de développement standards pour afficher ces informations :

   1. Cliquez sur le menu Chrome (more_vert) dans la barre d'outils du navigateur.
   2. Sélectionnez Plus d'outils > Outils de développement.
   3. Cliquez sur l'onglet Réseau.
   4. À partir de votre application ou de votre ligne de commande, envoyez la requête.
   5. Dans le volet affichant l'activité du réseau, localisez la requête.
   6. Dans la colonne Name (Nom), cliquez sur le nom correspondant à la requête.
   7. Cliquez sur l'onglet Headers (En-têtes) pour voir les en-têtes de réponse ou sur l'onglet Response (Réponse) pour voir le contenu de la réponse.

   Si vous ne voyez ni requête ni réponse, il est possible que votre navigateur ait mis en cache une tentative de requête de pré-vérification ayant échoué précédemment. Si vous videz le cache de votre navigateur, cela devrait également vider le cache de pré-vérification. Dans le cas contraire, diminuez la valeur MaxAgeSec dans votre configuration CORS (la valeur par défaut est 1800 (30 minutes) si elle n'est pas spécifiée), attendez pendant la durée de l'ancienne valeur MaxAgeSec, puis renouvelez la requête. Cela entraîne l'exécution d'une nouvelle requête de pré-vérification, qui récupère la nouvelle configuration CORS et purge les entrées du cache. Une fois que vous avez résolu votre problème, augmentez à nouveau la valeur MaxAgeSec afin de réduire le trafic de pré-vérification dans le bucket.

4. Assurez-vous que la requête comporte un en-tête Origin et que la valeur de celui-ci correspond à au moins l'une des valeurs Origins figurant dans la configuration CORS du bucket. Notez que le schéma, l'hôte et le port des valeurs doivent correspondre exactement. Voici quelques exemples de correspondances acceptables :

   • http://origin.example.com correspond à http://origin.example.com:80 (car 80 est le port HTTP par défaut), mais ne correspond pas à https://origin.example.com, ni à http://origin.example.com:8080, http://origin.example.com:5151 et http://sub.origin.example.com.

   • https://example.com:443 correspond à https://example.com, mais pas à http://example.com ni à http://example.com:443.

   • http://localhost:8080 ne correspond exactement qu'à http://localhost:8080, et non à http://localhost:5555 ni à http://localhost.example.com:8080.

5. Pour les requêtes simples, assurez-vous que la méthode HTTP de la requête correspond à au moins l'une des valeurs Methods de la configuration CORS du bucket. Pour les requêtes de pré-vérification, assurez-vous que la méthode spécifiée dans Access-Control-Request-Method correspond à au moins l'une des valeurs Methods.

6. Pour les requêtes de pré-vérification, vérifiez si elles incluent un ou plusieurs en-têtes Access-Control-Request-Header. Le cas échéant, assurez-vous que chaque valeur Access-Control-Request-Header correspond à une valeur ResponseHeader de la configuration CORS du bucket. Tous les en-têtes nommés dans Access-Control-Request-Header doivent figurer dans la configuration CORS pour que la requête de pré-vérification aboutisse et pour inclure les en-têtes CORS dans la réponse.

Codes d'erreur

Vous trouverez ci-dessous des codes d'état HTTP courants que vous pouvez rencontrer.

400 Bad Request

Problème : lors d'une importation avec reprise, j'ai reçu cette erreur et le message Failed to parse Content-Range header..

Solution : la valeur que vous avez utilisée dans l'en-tête Content-Range n'est pas valide. Par exemple, la valeur Content-Range: */* n'est pas valide et doit être spécifiée sous la forme Content-Range: bytes */*. Si vous rencontrez cette erreur, votre importation avec reprise actuelle n'est plus active, et vous devez en lancer une nouvelle.

400 : Erreurs spécifiques à Storage Intelligence

Les sections suivantes décrivent les erreurs courantes que vous pouvez rencontrer lorsque vous configurez ou gérez Storage Intelligence pour une ressource.

400 : Nom de bucket non valide

Problème : lorsque vous configurez ou gérez Storage Intelligence pour une ressource, vous pouvez recevoir cette erreur et le message The specific bucket is not valid..

Solution : L'URL que vous avez utilisée dans la requête n'est pas valide. L'URL doit répondre aux exigences suivantes :

• locations/global est le seul emplacement accepté pour Storage Intelligence. Aucun autre emplacement n'est accepté.
• Storage Intelligence est au singulier dans l'URL, et non au pluriel.

Voici un exemple d'URL valide :

curl -X PATCH -H "Content-Type: application/json" -d
    '{"edition_config": "STANDARD" }'
    -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://storage.s3nsapis.fr/v2/projects/my-project/locations/global/storageIntelligence?updateMask=edition_config"

400 : Argument non valide – Masque de mise à jour vide

Problème : lorsque vous configurez ou gérez Storage Intelligence pour une ressource, vous pouvez recevoir cette erreur et le message Empty UPDATE_MASK in the request..

Solution : UPDATE_MASK est la liste des noms de champs mis à jour par la requête, séparés par une virgule. Les noms de champs utilisent le format FieldMask et font partie de la ressource StorageIntelligence. Pour mettre à jour la configuration Storage Intelligence d'une ressource, utilisez un UPDATE_MASK valide dans la requête. Une valeur vide n'est pas acceptée.

400 : chemin du masque de mise à jour non valide

Problème : lorsque vous configurez ou gérez Storage Intelligence pour une ressource, vous pouvez recevoir cette erreur et le message Invalid UPDATE_MASK paths..

Solution : Si vous utilisez un nom de champ non valide dans UPDATE_MASK, un message d'erreur s'affiche. UPDATE_MASK est la liste des noms de champs que la requête met à jour, séparés par une virgule. Les noms de champs utilisent le format FieldMask et font partie de la ressource IntelligenceConfig. Pour mettre à jour la configuration Storage Intelligence d'une ressource, assurez-vous que chaque nom de champ listé dans UPDATE_MASK est un champ valide dans la ressource IntelligenceConfig.

400 : le champ n'est pas modifiable

Problème : lorsque vous configurez ou gérez Storage Intelligence pour une ressource, vous pouvez recevoir cette erreur et le message Invalid UPDATE_MASK: UPDATE_TIME field is not editable..

Solution : UPDATE_MASK est la liste des noms de champs mis à jour par la requête, séparés par une virgule. Les noms de champs utilisent le format FieldMask et font partie de la ressource IntelligenceConfig. Si vous essayez de modifier un champ non modifiable, un message d'erreur s'affiche. Supprimez le champ non modifiable de Update_Mask, puis réessayez.

400 : Valeur incorrecte

Problème : lorsque vous configurez ou gérez Storage Intelligence pour une ressource, vous pouvez recevoir cette erreur et le message Invalid value at storage_intelligence.edition_config..

Solution : Si vous essayez d'utiliser une valeur non valide pour le champ edition_config, un message d'erreur s'affiche. Les valeurs autorisées sont INHERIT, STANDARD et DISABLED. Vérifiez la valeur, puis réessayez.

400 : filtre non vide

Problème : Lorsque vous mettez à jour la configuration Storage Intelligence pour une ressource, vous pouvez recevoir cette erreur et le message Non-empty filter cannot be specified for INHERIT or DISABLED edition configuration..

Solution : Lorsque vous mettez à jour Storage Intelligence edition_config vers INHERIT ou DISABLED, vous ne pouvez pas utiliser de filtres de bucket dans la requête. Supprimez les filtres de la requête, puis réessayez.

400 : Valeurs de bucket ou d'emplacement vides dans le filtre

Problème : Lorsque vous mettez à jour la configuration Storage Intelligence pour une ressource, vous pouvez recevoir cette erreur et le message Empty location or bucket values in filter..

Solution : Lorsque vous mettez à jour la configuration Storage Intelligence et que vous utilisez un filtre de bucket dans la requête, une erreur se produit si la valeur de location ou bucket est une chaîne vide. Indiquez une valeur valide pour location ou bucket, puis réessayez.

401 Unauthorized

Problème: Les requêtes adressées à un bucket public échouent directement avec une réponse HTTP 401: Unauthorized et une réponse Authentication Required.

Solution : Vérifiez que votre client ou tout proxy intermédiaire n'ajoute pas d'en-tête Authorization aux requêtes à Cloud Storage. Toute requête comportant un en-tête Authorization, même si elle est vide, est validée comme s'il s'agissait d'une tentative d'authentification.

403 Account Disabled

Problème : J'ai essayé de créer un bucket, mais une erreur 403 Account Disabled s'est affichée.

Solution : Cette erreur indique que vous n'avez pas encore activé la facturation pour le projet associé. Pour connaître la procédure à suivre, consultez la section Activer la facturation pour un projet.

403 Forbidden

Problème : Je devrais être autorisé à accéder à un bucket ou à un objet spécifique, mais lorsque j'essaie d'y accéder, une erreur 403 - Forbidden s'affiche avec un message semblable à celui-ci : example@email.com does not have storage.objects.get access to the Google Cloud Storage object.

Solution : il vous manque une autorisation IAM, pour le bucket ou l'objet, requise pour traiter la requête. Si vous pensez pouvoir effectuer la requête mais que cela s'avère impossible, effectuez les vérifications suivantes :

1. Le bénéficiaire mentionné dans le message d'erreur est-il celui auquel vous vous attendiez ? Si le message d'erreur fait référence à une adresse e-mail inattendue ou à un "appelant anonyme", votre requête n'utilise pas les identifiants prévus. Cela peut être dû au fait que l'outil que vous utilisez pour effectuer la requête a été configuré avec les identifiants d'un autre alias ou d'une autre entité, ou que la requête est effectuée en votre nom par Compte de service.

2. L'autorisation référencée dans le message d'erreur est-elle bien celle dont vous aviez besoin ? Si l'autorisation est inattendue, il est probable que l'outil que vous utilisez nécessite un accès supplémentaire pour traiter votre requête. Par exemple, pour supprimer des objets d'un bucket de manière groupée, gcloud doit d'abord créer une liste d'objets dans le bucket à supprimer. Cette partie de l'action de suppression groupée nécessite l'autorisation storage.objects.list, ce qui peut être assez surprenant, étant donné que l'objectif est la suppression d'objet, qui ne nécessite normalement que l'autorisation storage.objects.delete. Si c'est la cause de votre message d'erreur, assurez-vous que les rôles IAM disposant des autorisations supplémentaires nécessaires vous sont bien attribués.

3. Disposez-vous du rôle IAM sur la ressource prévue ou la ressource parente ? Par exemple, si vous disposez du rôle Storage Object Viewer pour un projet et que vous essayez de télécharger un objet, assurez-vous que l'objet se trouve dans un bucket situé dans le projet. L'autorisation Storage Object Viewer vous a peut être été attribuée par inadvertance pour un autre projet.

4. Votre autorisation d'accéder à un bucket ou à un objet spécifique est-elle donnée via une valeur d'usage ? La suppression de l'accès accordé à une valeur d'usage peut entraîner la perte d'accès aux ressources pour les comptes principaux précédemment activés.

   Par exemple, supposons que jane@example.com dispose du rôle de base Propriétaire (roles/owner) pour un projet nommé my-example-project et que la stratégie IAM du projet accorde le rôle de créateur de l'espace de stockage (roles/storage.objectCreator) à la valeur d'usage projectOwner:my-example-project. Cela signifie que jane@example.com dispose des autorisations associées au rôle Créateur des objets de l'espace de stockage pour les buckets dans my-example-project. Si cette autorisation est supprimée, jane@example.com perd les autorisations associées au rôle "Storage Object Creator".

   Dans un tel scénario, vous pouvez récupérer l'accès au bucket ou à l'objet en vous accordant les autorisations au niveau du bucket ou de l'objet nécessaires pour effectuer les actions dont vous avez besoin.

5. Existe-t-il une stratégie de refus IAM qui vous empêche d'utiliser certaines autorisations ? Vous pouvez contacter l'administrateur de votre organisation pour savoir si une stratégie de refus IAM a été mise en place.

403 : Autorisation refusée

Problème : Erreur "Autorisation refusée" lorsque vous configurez ou gérez la configuration Storage Intelligence pour une ressource.

Solution : Si vous recevez une erreur d'autorisation refusée avec un message semblable à permission storage.intelligenceConfigs.update lorsque vous configurez et gérez Storage Intelligence pour une ressource, consultez la section sur les autorisations pour l'opération que vous souhaitez effectuer. Pour résoudre ce problème, accordez les autorisations appropriées. Vous pouvez accorder des autorisations de plusieurs façons :

• Accordez des autorisations IAM au même niveau de la hiérarchie des ressourcesTrusted Cloud by S3NS que celui sur lequel vous activez Storage Intelligence.
• Assurez-vous qu'une ressource de niveau supérieur dans la hiérarchie des ressources Trusted Cloud by S3NS transmet les autorisations à la ressource enfant.

409 Conflict

Problème : J'ai essayé de créer un bucket, mais l'erreur suivante s'est affichée :

409 Conflict. Sorry, that name is not available. Please try a different one.

Solution : Le nom de bucket que vous avez essayé d'utiliser (par exemple, gs://cats ou gs://dogs) est déjà attribué. Cloud Storage utilise un espace de noms global. Vous ne pouvez donc pas nommer un bucket avec le même nom qu'un bucket existant. Choisissez un nom qui n'est pas déjà utilisé.

412 Custom constraints violated

Problème : Mes requêtes sont rejetées avec une erreur 412 orgpolicy.

Problème : Mes requêtes sont rejetées avec une erreur 412 Multiple constraints were violated.

Solution : Vérifiez auprès de votre équipe d'administrateurs de la sécurité si le bucket auquel vous envoyez des requêtes est affecté par une règle d'administration utilisant une contrainte personnalisée. Votre bucket peut également être affecté par différentes règles d'administration qui entrent en conflit. Par exemple, une règle spécifie que les buckets doivent utiliser la classe de stockage standard, et une autre règle que les buckets doivent avoir la classe de stockage Coldline.

429 : Too Many Requests

Problème : Mes requêtes sont rejetées avec une erreur 429 Too Many Requests.

Solution : Vous atteignez la limite du nombre de requêtes autorisées par Cloud Storage pour une ressource donnée. Consultez la section sur les quotas Cloud Storage pour plus d'informations sur les limites dans Cloud Storage.

• Si votre charge de travail comprend des milliers de requêtes par seconde envoyées à un bucket, consultez les consignes liées au taux de requêtes et à la distribution des accès pour en savoir plus sur les bonnes pratiques, y compris l'augmentation progressive de votre charge de travail, et pour éviter les noms de fichiers séquentiels.

• Si votre charge de travail utilise potentiellement 50 Gbit/s ou plus de sortie réseau vers des emplacements spécifiques, vérifiez votre utilisation de la bande passante pour vous assurer que vous ne dépassez pas un quota de bande passante.

Diagnostiquer les erreurs de la console Trusted Cloud

Problème : Lorsque j'utilise la console Trusted Cloud pour effectuer une opération, un message d'erreur générique s'affiche. Par exemple, un message d'erreur s'affiche lorsque j'essaie de supprimer un bucket, mais je ne vois pas les raisons de l'échec de l'opération.

Solution : Utilisez les notifications de la console Trusted Cloud pour afficher des informations détaillées sur l'opération ayant échoué :

1. Cliquez sur le bouton Notifications (notifications) dans l'en-tête de la console Trusted Cloud .

   Un menu déroulant affiche les dernières opérations effectuées par la consoleTrusted Cloud .

2. Cliquez sur l'élément dont vous souhaitez en savoir plus.

   Une page s'ouvre et affiche des informations détaillées sur l'opération.

3. Cliquez sur chaque ligne pour développer les informations détaillées sur l'erreur.

Problème : Lorsque j'utilise la console Trusted Cloud , aucune colonne particulière ne s'affiche.

Solution : Pour afficher une colonne particulière dans la console Trusted Cloud , cliquez sur l'icône Options d'affichage des colonnes (view_column), puis sélectionnez la colonne que vous souhaitez afficher.

Dossiers gérés et simulés

Problème : J'ai supprimé certains objets de mon bucket, et le dossier qui les contient n'apparaît plus dans la console Trusted Cloud .

Solution : Bien que la console Trusted Cloud affiche le contenu de votre bucket comme s'il existait une structure de répertoires, les dossiers n'existent pas fondamentalement dans Cloud Storage. Par conséquent, lorsque vous supprimez tous les objets ayant un préfixe commun d'un bucket, l'icône de dossier représentant ce groupe d'objets n'apparaît plus dans la console Trusted Cloud .

Problème : Je ne parviens pas à créer de dossiers gérés.

Solution : pour créer des dossiers gérés, assurez-vous que les conditions suivantes sont remplies :

• Vous disposez d'un rôle IAM contenant l'autorisation storage.managedfolders.create, par exemple le rôle Administrateur des objets de l'espace de stockage (roles/storage.objectAdmin). Pour obtenir des instructions sur l'attribution des rôles, consultez la page Utiliser les autorisations IAM.

• L'accès uniforme au niveau du bucket est activé sur le bucket dans lequel vous souhaitez créer des dossiers gérés.

• Il n'existe aucune condition IAM sur le bucket ou le projet qui utilise le type de ressource de bucket (storage.googleapis.com/Bucket) ou le type de ressource d'objet (storage.googleapis.com/Object). Si un bucket d'un projet dispose d'une condition IAM qui utilise l'un de ces types de ressources, les dossiers gérés ne peuvent être créés dans aucun des buckets de ce projet, même si la condition est supprimée ultérieurement.

Problème : Je ne parviens pas à désactiver l'accès uniforme au niveau du bucket, car mon bucket contient des dossiers gérés.

Solution : L'accès uniforme au niveau du bucket ne peut pas être désactivé s'il existe des dossiers gérés dans le bucket. Pour désactiver l'accès uniforme au niveau du bucket, vous devez d'abord supprimer tous les dossiers gérés du bucket.

Rendre des données publiques

Problème : J'essaie de rendre mes données publiques, mais une erreur liée à une règle d'administration s'affiche.

Solution : Certaines contraintes de règles d'administration peuvent vous empêcher de rendre vos données publiques. Par exemple, la contrainte de partage restreint au domaine (constraints/iam.allowedPolicyMemberDomains) limite le partage des ressources en fonction du domaine de l'organisation. En cas d'échec des règles d'administration, contactez votre administrateur pour qu'il vous accorde les autorisations au niveau du projet ou du bucket afin d'autoriser le partage de ressources en modifiant la règle d'administration pour la ressource d'organisation, de dossier ou de projet. Si vous continuez à rencontrer cette erreur après avoir remplacé la règle d'administration, vous devrez peut-être attendre quelques minutes pour que la modification prenne effet.

Problème : Je reçois un message d'erreur d'autorisation lorsque j'essaie de rendre mes données publiques.

Solution : Assurez-vous de disposer de l'autorisation storage.buckets.setIamPolicy ou storage.objects.setIamPolicy. Ces autorisations sont accordées, par exemple, dans le rôle Administrateur de l'espace de stockage (roles/storage.admin). Si vous disposez de l'autorisation storage.buckets.setIamPolicy ou de l'autorisation storage.objects.setIamPolicy et que vous obtenez toujours une erreur, votre bucket peut être soumis à la protection contre l'accès public, qui n'autorise pas l'accès à allUsers ou allAuthenticatedUsers. La protection contre l'accès public peut être définie directement sur le bucket, ou appliquée via une règle d'administration définie à un niveau supérieur.

Latence

Vous trouverez ci-dessous des problèmes de latence courants que vous pouvez rencontrer. En outre, le tableau de bord Service Health fournit des informations sur les incidents qui affectent les services Trusted Cloud by S3NS tels que Cloud Storage.Trusted Cloud by S3NS

Latence d'importation ou de téléchargement

Problème : J'ai constaté une latence accrue lors de l'importation ou du téléchargement.

Solution : Tenez compte des causes courantes de latence d'importation et de téléchargement suivantes :

• Contraintes de processeur ou de mémoire : le système d'exploitation de l'environnement concerné doit disposer d'outils permettant de mesurer la consommation des ressources locale, telles que l'utilisation du processeur et de la mémoire.

• Contraintes d'E/S disque : l'impact sur les performances peut être dû aux E/S du disque local.

Latence de la CLI ou des bibliothèques clientes

Problème : J'ai constaté une latence accrue lorsque j'accède à Cloud Storage avec la Google Cloud CLI ou l'une des bibliothèques clientes.

Solution : La gcloud CLI et les bibliothèques clientes relancent automatiquement les requêtes lorsqu'il est utile de le faire. Ce comportement peut augmenter de manière importante la latence telle qu'elle est perçue par l'utilisateur final. Utilisez la métrique Cloud Monitoring storage.googleapis.com/api/request_count pour vérifier si Cloud Storage diffuse de manière cohérente un code de réponse récupérable, tel que 429 ou 5xx.

Serveurs proxy

Problème : Je me connecte via un serveur proxy. Que dois-je faire ?

Solution : Pour vous connecter à Cloud Storage via un serveur proxy, vous devez autoriser l'accès aux domaines suivants :

• accounts.google.com pour créer des jetons d'authentification OAuth2
• oauth2.googleapis.com pour les échanges de jetons OAuth2
• *.googleapis.com pour les requêtes de stockage

Si votre serveur proxy ou votre stratégie de sécurité ne prennent pas en charge l'ajout à la liste d'autorisation par domaine, mais uniquement par bloc réseau IP, nous vous recommandons vivement de configurer votre serveur proxy pour toutes les plages d'adresses IP Google. Vous pouvez trouver les plages d'adresses en interrogeant les données WHOIS sur le site ARIN. Il est recommandé de vérifier régulièrement les paramètres de votre serveur proxy afin de vous assurer qu'ils correspondent aux adresses IP de Google.

Nous vous déconseillons de configurer votre serveur proxy avec des adresses IP individuelles obtenues à partir de recherches ponctuelles sur oauth2.googleapis.com et storage.s3nsapis.fr. Les services Google étant exposés via des noms DNS mappés sur un grand nombre d'adresses IP susceptibles de changer au fil du temps, la configuration de votre serveur proxy sur la base d'une recherche ponctuelle peut entraîner des échecs de connexion à Cloud Storage.

Si vos requêtes sont acheminées via un serveur proxy, vous devrez peut-être contacter votre administrateur réseau pour vous assurer que l'en-tête Authorization contenant vos identifiants n'est pas supprimé par le serveur. Si l'en-tête Authorization n'est pas présent, vos requêtes sont rejetées, et vous recevez une erreur MissingSecurityHeader.

Étape suivante

• Trouvez des réponses à d'autres questions sur Cloud Storage sur la page "Questions fréquentes".