À propos du cycle de vie des instances

Les instances Flexible Compute Unit (FCU) ont un cycle de vie spécifique depuis le moment où vous les lancez jusqu’au moment où vous les terminez. Vous pouvez gérer leur cycle de vie, ce qui a des conséquences sur les ressources qui lui sont allouées ou attachées.

Vue d’ensemble

Cycle de vie d’une instance

FR sch FCU InstanceLifecycle

Lancement

Lancer une instance correspond à la fois à la créer puis à la démarrer. Une fois l’instance lancée, elle est à l’état pending jusqu’à ce qu’elle soit créée, démarrée et prête à l’usage. L’état de l’instance passe alors à running.

Le fait de lancer une instance lui alloue les ressources matérielles correspondantes. Vous définissez la configuration matérielle du serveur qui l’héberge grâce à un type d’instance, et le système d’exploitation, sa configuration et possiblement des applications logicielles grâce à une image machine OUTSCALE (OMI). Pour en savoir plus, voir À propos des OMI.

L’instance reçoit un ID unique, ainsi qu’une adresse IP privée et un nom DNS privé associé qui peuvent uniquement être contactés depuis le Cloud. Si vous lancez une instance dans le Cloud public, elle reçoit également une adresse IP publique et un nom DNS public associé. Cette adresse IP publique est temporaire et change à chaque fois que vous arrêtez et démarrez l’instance. Pour en savoir plus, voir À propos des instances > Informations générales sur les instances.

  • Pour fixer une adresse IP publique à une instance du Cloud public ou pour ajouter une adresse IP publique fixe à une instance d’un Virtual Private Cloud (VPC), vous pouvez lui attacher une External IP (EIP) puis utiliser le tag OUTSCALE osc.fcu.eip.auto-attach qui la fixe même lors du processus d’arrêt et de démarrage de l’instance. Pour en savoir plus, voir À propos des EIP

  • Pour lancer une instance dans le Cloud public sans adresse IP publique et sans nom DNS public associé, utilisez le tag OUTSCALE private-only.

Vous pouvez également attacher des flexible network interfaces à une instance lors de son lancement ou après sa création. Pour en savoir plus, voir Flexible network interfaces (FNI).

Arrêt et démarrage

Vous pouvez arrêter une instance en cours de fonctionnement (running) à tout moment, puis la démarrer à nouveau. Arrêter une instance avec l’API correspond à la couper avec la commande du système d’exploitation.

Vous pouvez également forcer l’arrêt d’une instance. Cette action arrête l’instance sans quitter proprement les applications en cours d’utilisation.

Forcer l’arrêt d’une instance peut endommager son système.

Lorsque vous arrêtez une instance, celle-ci passe à l’état stopping, puis à l’état stopped. Lorsque vous démarrez une instance arrêtée, celle-ci est à l’état pending, puis passe ensuite à l’état running.

Lors de l’arrêt et du démarrage de l’instance, celle-ci conserve :

  • Son ID

  • Son adresse IP privée et son nom DNS privé associé

  • L’EIP qui lui est attachée et fixée avec le tag OUTSCALE osc.fcu.eip.auto-attach (s’il y en a une)

Si l’instance n’est pas taguée avec le tag OUTSCALE osc.fcu.eip.auto-attach, l’EIP est détachée de l’instance lorsque celle-ci est arrêtée.

  • Les volumes qui lui sont attachés (s’il y en a)

À l’inverse, l’adresse IP publique et le nom DNS public associé qui sont attribués à une instance du Cloud public lors de son lancement changent lorsque celle-ci est arrêtée. La mémoire est également effacée.

Lorsqu’une instance est à l’état stopped, vous pouvez modifier ses attributs comme le type d’instance (quantité de vCores et de mémoire). Pour en savoir plus, voir Modifier un attribut d’une instance.

Il est également recommandé d’arrêter l’instance si vous souhaitez traiter un volume attaché à celle-ci. Pour ce faire, détachez le volume de l’instance lorsque celle-ci est arrêtée et attachez-le à une autre instance afin de le traiter. Lorsque vous réattachez le volume à l’instance d’origine arrêtée, assurez-vous d’utiliser le même nom de périphérique que celui précisé dans le block device mapping avant de démarrer l’instance. Pour en savoir plus, voir Attacher un volume à une instance, Détacher un volume d’une instance et Définir des block device mappings.
Si souhaitez arrêter une instance qui est enregistrée auprès d’un load balancer, il est recommandé de la désenregistrer avant de l’arrêter, puis de la démarrer avant de l’enregistrer à nouveau si besoin. Pour en savoir plus, voir Load Balancing Unit (LBU).

Arrêt forcé

Si vous n’arrivez pas à arrêter votre instance avec un arrêt classique, vous pouvez également forcer celle-ci à s’arrêter. Forcer l’arrêt d’une instance correspond à la débrancher, ce qui signifie que le système peut ne pas s’éteindre correctement.

Forcer l’arrêt d’une instance peut endommager le système et corrompre les données. Assurez-vous que vous n’en avez plus besoin ou que vous avez une sauvegarde.

Vous pouvez ouvrir la console et ainsi vérifier s’il y a un problème. Pour ouvrir la console, cliquez sur Sortie console dans la page Instances de Cockpit.

La liste ci-dessous recense les causes classiques pouvant expliquer pourquoi une instance ne s’arrête pas :

  • Un programme est en cours, ce qui empêche l’instance de s’arrêter.
    La cause la plus fréquente est qu’un programme utilise un filesystem, ce qui signifie qu’un programme est toujours en cours d’exécution sur un volume. Ceci empêche le filesystem d’être démonté, ce qui est requis pour que l’instance s’arrête. Vous devez donc vous assurer qu’aucun programme n’utilise un filesystem (par exemple, NFS ou CRFS). Si c’est le cas, suivez l’une des trois options suivantes avant d’essayer d’arrêter l’instance à nouveau :

    • Attendez que le programme s’arrête.

    • Arrêtez le programme.

    • Démontez le volume sur lequel le programme est en cours d’exécution.

  • Une mise à jour est en cours (par exemple, une mise à jour Windows).

Ne forcez pas une instance à s’arrêter pendant une mise à jour. Ceci pourrait endommager votre instance ou l’empêcher de redémarrer. Certaines mises à jour peuvent prendre beaucoup de temps (plusieurs heures) sur les types d’instances de faible capacité.

  • Il y a des problèmes avec vos requêtes ACPI, qui permettent aux instances de s’arrêter convenablement.
    Les deux raisons principales sont :

    • L’instance est hors-service. Dans ce cas, les requêtes ACPI sont ignorées.

    • Les modules pci-hotplug et acpiphp ne sont pas installés sur votre instance, donc les requêtes ACPI ne sont pas supportées. Ceci peut se produire si vous avez utilisé votre propre OMI pour lancer votre instance.
      Vous pouvez vérifier dans le répertoire /etc/modules si ces modules sont installés ou non :

# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
# Parameters can be specified after the module name.
pci-hotplug
acpiphp

Si les modules ne sont pas installés, vous pouvez créer votre propre OMI en utilisant une OMI officielle et lancer une nouvelle instance.

Si l’instance ne s’arrête pas malgré l’arrêt forcé, contactez notre équipe Support. Attention, le support n’aura pas d’autre choix que de couper votre instance, ce qui pourrait corrompre vos données. Pensez donc à les sauvegarder.

Redémarrage

Vous pouvez redémarrer une instance en cours de fonctionnement à tout moment si besoin avec l’API, ce qui correspond à redémarrer le système d’exploitation. L’instance redémarre sans suivre le processus d’arrêt et démarrage classique.

L’instance reste en fonctionnement (running) et conserve les ressources qui lui sont allouées. Les données stockées dans la mémoire restent disponibles après le redémarrage de l’instance.

Suppression

Vous pouvez terminer (supprimer) une instance dont vous n’avez plus besoin. Les instances terminées ne peuvent être récupérées. L’instance passe à l’état shutting-down, puis l’état terminated une fois la suppression effectuée. L’instance reste visible à l’état terminated pendant 1 heure, sans possibilité de la récupérer.

Lorsque vous terminez une instance, ses ressources matérielles correspondantes sont libérées et les données stockées dans la mémoire sont effacées. Si une EIP est attachée à l’instance, celle-ci est libérée mais reste allouée à votre compte.

Le comportement des volumes BSU lorsque vous terminez l’instance à laquelle ils sont attachés dépend du block device mapping. Par défaut, le volume système de l’instance est supprimé alors que les autres volumes attachés sont détachés. Pour en savoir plus, voir Définir des block device mappings.

Vous pouvez également configurer deux types de protection contre la suppression :

  • DisableApiTermination : Cet attribut vous permet d’empêcher la suppression de l’instance (par défaut, la suppression est autorisée).

  • InstanceInitiatedShutDownBehavior : Cet attribut vous permet de définir le comportement de l’instance lorsque vous l’arrêtez ou la terminez. Par défaut ou si paramétré sur stop, l’instance est arrêtée. Si paramétré sur restart, l’instance est arrêtée puis automatiquement redémarrée. Si paramétré sur terminate, l’instance est arrêtée puis terminée. Vous pouvez par exemple automatiquement terminer l’instance à la fin d’une application en paramétrant cet attribut sur terminate et en demandant à l’instance de s’arrêter quand l’application est fermée.

Ces deux attributs de protection contre la suppression peuvent être définis au lancement de l’instance et modifiés par la suite. Pour en savoir plus, voir Modifier un attribut d’une instance.

Pages connexes