Résoudre les problèmes liés aux disques saturés et au redimensionnement des disques

Linux

Cette page décrit les problèmes courants que vous pouvez rencontrer lors du redimensionnement d'un disque persistant ou lorsque votre disque persistant est saturé, et explique comment les résoudre.

Avant de commencer

Créez toujours un instantané de votre disque avant d'effectuer les étapes de dépannage afin de vous assurer que vos données sont sauvegardées.
Si ce n'est pas déjà fait, configurez l'authentification. L'authentification est le processus permettant de valider votre identité pour accéder aux services et aux API Google Cloud. Pour exécuter du code ou des exemples depuis un environnement de développement local, vous pouvez vous authentifier auprès de Compute Engine comme suit :

Sélectionnez l'onglet correspondant à la façon dont vous prévoyez d'utiliser les exemples de cette page :
Console

Lorsque vous utilisez la console Google Cloud pour accéder aux services et aux API Google Cloud, vous n'avez pas besoin de configurer l'authentification.
gcloud
1. Installez Google Cloud CLI, puis initialisez-la en exécutant la commande suivante :
```
gcloud init
```
  Remarque : Si vous avez déjà installé gcloud CLI, assurez-vous que vous disposez de la dernière version en exécutant gcloud components update.
2. Définissez une région et une zone par défaut.
REST

Pour utiliser les exemples d'API REST de cette page dans un environnement de développement local, vous devez utiliser les identifiants que vous fournissez à gcloud CLI.

Taux d'erreur limité lors de la modification d'un disque

Voici les erreurs courantes que vous pouvez rencontrer lorsque vous essayez de modifier votre disque persistant extrême ou Google Cloud Hyperdisk. Ces erreurs peuvent apparaître à plusieurs endroits, par exemple dans la sortie de la console série ou dans les journaux d'application.

Disk cannot be resized due to being rate limited.

Cannot update provisioned iops due to being rate limited.

Cannot update provisioned throughput due to being rate limited.

Passer en revue les limites temporelles suivantes pour la modification des disques :

Vous ne pouvez redimensionner un volume de disque persistant extrême ou Hyperdisk Throughput qu'une fois par période de 6 heures.
Vous ne pouvez redimensionner un volume Hyperdisk Extreme qu'une fois par période de quatre heures.
Vous ne pouvez modifier les IOPS ou le débit provisionné pour un volume Hyperdisk qu'une fois par période de quatre heures.

Pour résoudre ces erreurs, attendez la durée requise depuis votre dernière modification avant d'essayer de modifier à nouveau les disques.

Erreurs de capacité des disques

Disques saturés

Voici les erreurs courantes que vous pouvez rencontrer lorsque votre disque persistant atteint sa capacité maximale. Ces erreurs peuvent apparaître à plusieurs endroits, par exemple dans la sortie de la console série ou dans les journaux d'application.

No space left on device

Not enough storage is available to process this command

Pour résoudre ce problème, procédez comme suit :

Créez un instantané du disque.
Supprimez les fichiers dont vous n'avez pas besoin sur le disque pour libérer de l'espace.
Si votre disque nécessite encore davantage d'espace, redimensionnez le disque.

VM inaccessible en raison d'un disque de démarrage saturé

Votre VM peut devenir inaccessible si son disque de démarrage est saturé. Ce scénario peut être difficile à identifier : il n'est pas toujours évident de savoir si le problème de connectivité des VM est dû à un disque de démarrage saturé. Vous trouverez ci-dessous des exemples d'erreurs courantes que vous pouvez rencontrer si vous ne pouvez pas accéder à votre VM à partir de Google Cloud CLI, en raison d'une saturation du disque de démarrage :

  Network error: Software caused connection abort

  ERROR: (gcloud.compute.ssh) Could not SSH into the instance.  It is possible
  that your SSH key has not propagated to the instance yet. Try running this
  command again.  If you still cannot connect, verify that the firewall and
  instance are set to accept ssh traffic.

  You cannot connect to the VM instance because of an unexpected error. Wait a
  few moments and then try again.

  No space left on device

  ERROR Exception calling the response handler. [Errno 2] No usable temporary
  directory found in ['/tmp', '/var/tmp', '/usr/tmp', '/']...

Pour résoudre les problèmes ci-dessus, procédez comme suit :

Vérifiez que l'échec SSH de la VM est dû à un disque de démarrage saturé :
```
gcloud compute instances tail-serial-port-output VM_NAME
```
Si le disque de démarrage est saturé, la sortie contient le message No space left on device.
Si vous ne l'avez pas déjà fait, créez un instantané du disque de démarrage de la VM.
Essayez de redémarrer la VM.
Si vous ne parvenez toujours pas à accéder à la VM, procédez comme suit :
1. Arrêtez la VM :
```
gcloud compute instances stop VM_NAME
```
  Remplacez VM_NAME par le nom de votre VM.
2. Augmentez la taille du disque de démarrage:
```
gcloud compute disks resize BOOT_DISK_NAME --size DISK_SIZE
```
  Remplacez les éléments suivants :
  - BOOT_DISK_NAME : nom du disque de démarrage de votre VM
  - DISK_SIZE : nouvelle taille du disque de démarrage en gigaoctets
  Par exemple, pour redimensionner un disque nommé example-disk-1 en 6 Go, exécutez la commande suivante:
```
gcloud compute disks resize example-disk-1 --size=6GB
```
3. Démarrez la VM :
```
gcloud compute instances start VM_NAME
```
Essayez à nouveau de vous connecter en SSH à la VM. Si vous ne parvenez toujours pas à accéder à la VM, effectuez l'une des opérations suivantes :
- Créez un disque à partir d'un instantané. Pour en savoir plus, consultez la section Récupérer une VM inaccessible ou un disque de démarrage complet.
- Démarrez temporairement la VM en mode secours, en utilisant l'outil Open Source GCE Rescue, et suivez la procédure disponible dans Problèmes liés au système de fichiers.

Problèmes liés au système de fichiers

Redimensionnement du système de fichiers

Après avoir redimensionné le disque de démarrage d'une VM, la plupart des VM redimensionnent le système de fichiers racine et effectuent un redémarrage. Toutefois, pour certains types d'images de VM, vous devrez peut-être redimensionner le système de fichiers manuellement. Si votre VM n'est pas compatible avec le redimensionnement automatique du système de fichiers racine, ou si vous avez redimensionné un disque persistant de données (non amorçable), vous devez redimensionner manuellement le système de fichiers et les partitions.

Pour vérifier si votre système de fichiers racine a été développé automatiquement après avoir redimensionné le disque de démarrage de la VM, procédez comme suit :

Vérifiez si votre VM a redimensionné le disque de démarrage en utilisant l'une des méthodes suivantes :
- Inspectez la sortie de votre port série. Recherchez une ligne indiquant que la partition racine a été redimensionnée.
  
  Par exemple, sur les VM avec des images Debian, si le redimensionnement automatique a réussi, les journaux de la console incluent la ligne ... expand-root.sh[..]: Resizing ext4 filesystem on /dev/sda1.
- Si vous pouvez vous connecter en SSH à une VM Linux, exécutez la commande df -h pour vérifier l'espace disque disponible.
  
  Par exemple, ce résultat indique que le système de fichiers racine est plein à 92 % :
```
Filesystem                                    Size  Used Avail Use% Mounted on
udev                                           63G     0   63G   0% /dev
tmpfs                                          13G  1.4M   13G   1% /run
/dev/sda1                                     339G  315G   24G  92% /
```
Si votre VM n'a pas redimensionné le système de fichiers racine, redimensionnez manuellement le système de fichiers et les partitions.