Utilisation des instances

Le service de calcul pour Oracle Cloud Infrastructure permet de provisionner et de gérer des hôtes pour les calculs, nommés instances. Vous pouvez créer des instances quand vous le souhaitez afin de répondre à vos besoins en matière de calcul et d'application. Dès lors qu'une instance est créée, vous pouvez y accéder en toute sécurité à partir de votre ordinateur, la redémarrer, attacher et détacher des volumes, puis y mettre fin une fois que vous avez terminé.

Zones de sécurité

Les zone de sécurité garantissent que les ressources en nuage sont conformes aux principes de sécurité d'Oracle. Si une opération sur une ressource d'un compartiment de zone de sécurité enfreint une politique pour cette zone de sécurité, l'opération est refusée.

Les politiques de zone de sécurité suivantes ont une incidence sur la possibilité de créer des instances :

  • Le volume de démarrage d'une instance de calcul située dans une zone de sécurité doit également se trouver dans la même zone de sécurité.
  • Une instance de calcul qui n'est pas dans une zone de sécurité ne peut pas utiliser un volume de démarrage qui se trouve dans cette zone.
  • Une instance de calcul dans une zone de sécurité doit utiliser des sous-réseaux qui se trouvent également dans la même zone de sécurité.
  • Toutes les instances de calcul d'une zone de sécurité doivent être créées à l'aide d'images de plate-forme. Vous ne pouvez pas créer une instance de calcul à partir d'une image personnalisée dans une zone de sécurité.
Important

L'échec de la mise en oeuvre de l'une des politiques de zone de sécurité listées peut empêcher la création d'une instance.

Politique IAM requise pour l'utilisation des instances

Pour utiliser Oracle Cloud Infrastructure, un administrateur doit être membre d'un groupe auquel l'accès de sécurité est accordé dans une politique par un administrateur de location. Cet accès est requis que vous utilisiez la console ou l'API REST avec une trousse SDK, l'interface de ligne de commande ou un autre outil. Si vous obtenez un message indiquant que vous ne disposez pas de l'autorisation requise, vérifiez auprès de l'administrateur de la location quel type d'accès vous avez et dans quel compartiment votre accès fonctionne.

Conseil

Lorsque vous créez une instance, plusieurs autres ressources sont impliquées par exemple une image, un réseau en nuage et un sous-réseau. Ces autres ressources peuvent se trouver dans le même compartiment  que l'instance ou dans d'autres compartiments. Pour lancer l'instance, vous devez disposer du niveau d'accès requis pour chaque compartiment utilisé. Ceci est également vrai lorsque vous attachez un volume à une instance. Il n'est pas nécessaire que les deux soient dans le même compartiment, mais s'ils ne le sont pas, vous devez avoir le niveau d'accès requis pour chacun des compartiments.

Pour les administrateurs : La politique la plus simple permettant aux utilisateurs de créer, de modifier et de mettre fin (supprimer) est indiquée sous Autoriser les utilisateurs à lancer des instances de calcul. Elle donne au groupe indiqué l'accès général pour gérer les instances et les images, ainsi que le niveau d'accès requis pour attacher des volumes par blocs existants aux instances. Si le groupe spécifié n'a pas besoin de lancer des instances ou d'attacher des volumes, vous pouvez simplifier cette politique pour inclure seulement manage instance-family et supprimer les énoncés impliquant volume-family et virtual-network-family.

Si le groupe doit créer des volumes par blocs, il a besoin de pouvoir les gérer. Voir Autoriser les administrateurs de volumes à gérer les volumes par blocs, les sauvegardes et les groupes de volumes.

Si le groupe a besoin d'accéder spécifiquement aux images de la communauté, il aura besoin de la possibilité de lire les images de la communauté. Voir Publication des applications de communauté.

Pour en savoir plus sur les politiques, voir Gestion des domaines d'identité et Politiques communes. Pour des documents de référence sur l'écriture de politiques pour les instances, les réseaux en nuage ou d'autres ressources d'API des services de base, voir Informations détaillées sur les services de base.

Certaines tâches de calcul nécessitent des politiques supplémentaires, comme décrit dans les sections suivantes.

Catalogue d'images du partenaire

Si le groupe doit créer des instances basées sur des images de partenaire, il a besoin de l'autorisation manage pour la ressource app-catalog-listing afin de pouvoir créer des abonnements aux images dans le catalogue d'images du partenaire. Voir Autoriser les utilisateurs à indiquer les images du catalogue d'images du partenaire et à s'y abonner .

Accès SSH et Bureau à distance

Pour les utilisateurs : Pour vous connecter à une instance en cours d'exécution avec une connexion SSH (Secure Shell) ou Bureau à distance, vous n'avez pas besoin d'une politique IAM pour vous accorder l'accès. Toutefois, vous avez besoin de l'adresse IP publique de l'instance.

Pour les administrateurs : Si une politique existe qui permet aux utilisateurs de lancer une instance, elle permet probablement d'obtenir l'adresse IP de l'instance. La politique la plus simple pour ces deux opérations est indiquée sous Autoriser les utilisateurs à lancer des instances de calcul.

Il existe une politique plus restrictive qui permet au groupe spécifié d'obtenir l'adresse IP des instances existantes et d'utiliser des actions de configuration sur les instances (par exemple, arrêter ou démarrer l'instance), mais pas de lancer des instances ou d'y mettre fin. La politique suppose que les instances et le réseau en nuage sont rassemblés dans un seul compartiment (XYZ).

Allow group InstanceUsers to read virtual-network-family in compartment XYZ
Allow group InstanceUsers to use instance-family in compartment XYZ

Service de métadonnées d'instance (IMDS)

Pour les utilisateurs : Aucune politique IAM n'est requise si vous êtes connecté à l'instance et que vous utilisez cURL pour obtenir les métadonnées de l'instance.

Pour les administrateurs : Les utilisateurs peuvent également obtenir les métadonnées d'instance au moyen de l'API du service Calcul (par exemple, avec GetInstance). La politique sous Autoriser les utilisateurs à lancer des instances de calcul décrit cette capacité.

Pour exiger que les points d'extrémité IMDSv1 existants soient désactivés dans toutes les nouvelles instances créées, utilisez la politique suivante :

Allow group InstanceLaunchers to manage instances in compartment ABC 
  where request.instanceOptions.areLegacyEndpointsDisabled= 'true'

Réservations de capacité

Pour les administrateurs : Les exemples suivants montrent les politiques habituelles qui donnent accès aux réservations de capacité. Créez la politique dans la location de sorte que l'accès soit facilement accordé à tous les compartiments au moyen de l'héritage des politiques. Pour réduire la portée de l'accès aux réservations de capacité d'un compartiment particulier, indiquez ce compartiment au lieu de la location.

Type d'accès : Possibilité de lancer une instance dans une réservation.

Allow group InstanceLaunchers to use compute-capacity-reservations in tenancy
                            

Type d'accès : Possibilité de gérer les réservations de capacité.

Allow group InstanceLaunchers to manage compute-capacity-reservations in tenancy
                            

Exécuter une commande

Pour les administrateurs : Pour écrire une politique pour la fonction d'exécution de commande :

  1. Créez un groupe qui inclut les utilisateurs que vous souhaitez autoriser à émettre et annuler des commandes, et consulter la sortie des commandes pour les instances d'un compartiment. Ensuite, écrivez la politique suivante pour accorder l'accès au groupe :

    Allow group RunCommandUsers to manage instance-agent-command-family in compartment ABC
  2. Créez un groupe dynamique qui inclut les instances sur lesquelles vous souhaitez autoriser l'exécution des commandes. Par exemple, une règle à l'intérieur du groupe dynamique peut indiquer :

    any { instance.id1 = 'ocid1.instance.oc1.phx.<unique_ID_1>', instance.id2 = 'ocid2.instance.oc1.phx.<unique_ID_2>' }
  3. Écrivez la politique suivante pour accorder l'accès au groupe dynamique :
    Note

    Si vous créez une instance, puis l'ajoutez à un groupe dynamique, il faut compter 30 minutes pour que l'instance commence à scruter les commandes. Si vous créez d'abord le groupe dynamique, puis l'instance, l'instance commence à scruter les commandes dès qu'elle est créée.
    Allow dynamic-group RunCommandDynamicGroup to use instance-agent-command-execution-family in compartment ABC where request.instance.id=target.instance.id
  4. Pour permettre au groupe dynamique d'accéder au fichier de script à partir d'un seau du service Stockage d'objets et d'enregistrer la réponse dans un seau du service Stockage d'objets, écrivez les politiques suivantes :

    Allow dynamic-group RunCommandDynamicGroup to read objects in compartment ABC where all {target.bucket.name = '<bucket_with_script_file>'}
    Allow dynamic-group RunCommandDynamicGroup to manage objects in compartment ABC where all {target.bucket.name = '<bucket_for_command_output>'}

Types de lancement de réseau recommandés pour les instances de calcul

Lorsque vous créez une instance de machine virtuelle, par défaut Oracle Cloud Infrastructure choisit un type de réseau recommandé pour la carte vNIC en fonction de la forme d'instance et de l'image du système d'exploitation. L'interface réseau gère des fonctions telles que l'entrée/la sortie de disque et la communication réseau.

Les types de réseau suivants sont disponibles :

  • Réseau paravirtualisé : Pour les charges de travail à usage général telles que les applications d'entreprise, les microservices et les petites bases de données. Le réseau paravirtualisé offre également une flexibilité accrue pour utiliser la même image sur différentes plates-formes matérielles. Les images Linux avec réseau paravirtualisé prennent en charge la migration en direct pendant la maintenance de l'infrastructure.
  • Réseau assisté par matériel (SR-IOV) : Virtualisation d'E/S à racine unique. Pour les charges de travail à faible latence telles que la diffusion en continu de vidéos, les applications en temps réel et les bases de données volumineuses ou en grappe. Le réseau assisté par matériel (SR-IOV) utilise le pilote VFIO.
Important

Pour utiliser un type de réseau particulier, la forme et l'image doivent prendre en charge ce type de réseau.

Formes : Le tableau suivant indique les types de réseau par défaut et pris en charge pour les formes de machine virtuelle.

Forme Type de réseau par défaut Types de réseau pris en charge
Série VM.Standard1 SR-IOV Paravirtualisés, SR-IOV
Série VM.Standard2 Paravirtualisé Paravirtualisés, SR-IOV
VM.Standard3.Flex Paravirtualisé Paravirtualisés, SR-IOV
Série VM.Standard.E2 Paravirtualisé Paravirtualisés uniquement
VM.Standard.E3.Flex

Paravirtualisé

Paravirtualisés, SR-IOV
VM.Standard.E4.Flex

Paravirtualisé

Paravirtualisés, SR-IOV
VM.Standard.E5.Flex

Paravirtualisé

Paravirtualisés, SR-IOV
VM.Standard.E6. Champ flexible

Paravirtualisé

Paravirtualisés, SR-IOV
VM.Standard.A1.Flex1 Paravirtualisé Paravirtualisés, SR-IOV
Série VM.DenseIO1 SR-IOV Paravirtualisés, SR-IOV
Série VM.DenseIO2 Paravirtualisé Paravirtualisés, SR-IOV
VM.DenseIO.E4.Flex Paravirtualisé Paravirtualisés, SR-IOV
Série VM.GPU2 SR-IOV Paravirtualisés, SR-IOV
Série VM.GPU3 SR-IOV Paravirtualisés, SR-IOV
Série VM.GPU.A10 SR-IOV Paravirtualisés, SR-IOV
VM.Optimized3.Flex

Paravirtualisé

Paravirtualisés, SR-IOV

Images : Le réseau paravirtualisé est pris en charge sur les images de plate-forme suivantes :

  • Oracle Linux 9, Oracle Linux 8, Oracle Autonomous Linux 8.x, Oracle Autonomous Linux 7.x, Oracle Linux Cloud Developer 8 : Toutes les images.
  • Oracle Linux 7 : Images publiées en mars 2019 ou ultérieurement.
  • CentOS Stream 8, CentOS 7 : Images publiées à partir de juillet 2019.
  • Ubuntu 22.04, Ubuntu 20.04 : Toutes les images.
  • Ubuntu 18.04 : Images publiées en mars 2019 ou ultérieurement.
  • Windows Server 2022, Windows Server 2019 : Toutes les images.
  • Windows Server 2016, Windows Server 2012 R2 : Images publiées à partir d'août 2019.

Le réseau SR-IOV est pris en charge sur toutes les images de plate-forme, avec les exceptions suivantes :

  • Les images pour les formes basées sur ARM ne prennent pas en charge le réseau SR-IOV.
  • Sur Windows Server 2019 et Windows Server 2022, lorsqu'il est lancé à l'aide d'une forme de la série VM.Standard2, le réseau SR-IOV n'est pas pris en charge.
  • Sur Windows Server 2012 R2, le réseau SR-IOV est pris en charge sur les images de plate-forme publiées en avril 2021 ou ultérieurement.
  • L'option d'installation Server Core pour Windows Server ne prend pas en charge le réseau SR-IOV.

Dépannage des erreurs de création à l'aide de demandes de travail

Les demandes de travail vous permettent de surveiller les opérations de longue durée telles que les sauvegardes de base de données ou le provisionnement d'instances de calcul.

Si une opération telle que l'opération de création d'instance échoue ou si l'état de l'instance passe directement du provisionnement à l'arrêt, utilisez des demandes de travail pour déterminer où l'erreur est survenue dans le flux de travail. Des erreurs peuvent survenir en raison de problèmes de configuration ou de problèmes liés aux données d'utilisateur. Des erreurs synchrones se produisent lors de l'appel initial à l'API du service Calcul pour créer l'instance. Des erreurs asynchrones surviennent pendant le flux de travail de création d'instance qui se produit après l'appel d'API initial. Les demandes de travail saisissent les échecs de validation asynchrone. Un appel de l'API de création d'instance qui retourne une réponse HTTP 200 peut être suivi d'une erreur asynchrone lors du flux de travail de création d'instance suivant.

La réponse à l'appel de l'API REST contient l'OCID de la demande de travail dans l'en-tête opc-work-request-id. Vous pouvez surveiller le statut de la demande de travail à tout moment en appelant GetWorkRequest dans l'API de demandes de travail et en transmettant l'ID demande de travail trouvé dans l'en-tête opc-work-request-id. Si une erreur survient pendant le flux de travail, vous pouvez appeler ListWorkRequestErrors dans l'API de demandes de travail et transmettre l'ID demande de travail pour extraire une liste d'erreurs.

Pour des informations sur l'utilisation des demandes de travail pour dépanner les erreurs, voir Demandes de travail. Pour des informations détaillées sur les demandes de travail asynchrones, notamment sur le filtrage de la réponse à la demande et un exemple de demande et de réponse, voir Demandes de travail asynchrones.

Gestion des marqueurs pour une instance

Appliquer des marqueurs aux ressources afin de les organiser en fonction des besoins de l'entreprise. Vous pouvez appliquer des marqueurs lorsque vous créez une ressource, et vous pouvez mettre à jour une ressource plus tard pour ajouter, réviser ou supprimer des marqueurs. Pour des informations générales sur l'application de marqueurs, voir Marqueurs de ressource.

Pour gérer les marqueurs d'une instance :

  1. Ouvrez le menu de navigation et sélectionnez Calcul. Sous Calcul, sélectionnez Instances.
  2. Sélectionnez l'instance qui vous intéresse.

  3. Sélectionnez l'onglet Marqueurs pour voir ou modifier les marqueurs existants. Ou cliquez sur Actions supplémentaires, puis sur Ajouter des marqueurs pour en ajouter d'autres.