Dans cet article, nous décrivons les bonnes pratiques de génération sur des machines virtuelles spot Azure et nous incluons un exemple de scénario déployable. Les machines virtuelles spot offrent un accès à la capacité de calcul avec des remises considérables par rapport aux machines virtuelles ordinaires. Cette remise en fait une solution attrayante pour les organisations qui cherchent à optimiser les coûts, mais les économies sont soumises à une condition. Les machines virtuelles spot peuvent perdre leur accès au calcul à tout moment. Nous appelons ce processus « éviction ». Les charges de travail s’exécutant sur des machines virtuelles spot doivent être en mesure de gérer ces interruptions de calcul. La charge de travail appropriée et un mécanisme d’orchestration flexible sont les clés de la réussite. Voici nos recommandations pour créer sur des machines virtuelles spot.
Comprendre les machines virtuelles spot
Au niveau technique, les machines virtuelles spot sont identiques aux machines virtuelles normales. Elles utilisent les mêmes images, le même matériel et les mêmes disques, qui se traduisent par les mêmes performances. La différence entre les machines virtuelles spot et normales se résume à la priorité et à la disponibilité. Les machines virtuelles spot n’ont aucune priorité pour accéder à la capacité de calcul et elles n’ont aucune garantie de disponibilité après avoir accédé à cette capacité de calcul. Nous allons aborder plus en détail la priorité et la disponibilité.
Aucun accès prioritaire. Les machines virtuelles ordinaires ont accès en priorité à la capacité de calcul. Elles accèdent à la capacité de calcul chaque fois qu’elles la demandent. Les machines virtuelles spot, quant à elles, sont déployées uniquement quand il y a une capacité de calcul de rechange, et elles restent en cours d’exécution uniquement quand aucune machine virtuelle ordinaire n’a besoin du matériel sous-jacent.
Aucune garantie de disponibilité. Les machines virtuelles spot n’ont aucune garantie de disponibilité. Elles ne sont associées à aucun contrat de niveau de service (SLA). Les machines virtuelles spot peuvent perdre l’accès à la capacité de calcul immédiatement ou à tout moment après le déploiement (éviction). Les machines virtuelles spot sont moins chères en raison de la possibilité d’éviction. Chaque fois qu’Azure a besoin de la capacité de calcul, une notification d’éviction est envoyée et la machine virtuelle spot est supprimée. Azure fournit un préavis d’au moins 30 secondes avant l’éviction. Pour plus d’informations, consultez « Superviser en continu afin de détecter l’éviction » dans cet article.
Comprendre les tarifs des machines virtuelles spot
Les machines virtuelles spot peuvent être jusqu’à 90 % moins chères que les machines virtuelles ordinaires (paiement à l’utilisation). La remise varie en fonction de la demande, de la taille de la machine virtuelle, de la région de déploiement et du système d’exploitation. Nous vous recommandons d’utiliser l’outil de tarification des machines virtuelles Azure Spot pour obtenir une estimation des économies réalisables. Pour plus d'informations, consultez les pages suivantes :
- Outil de tarification des machines virtuelles Azure Spot
- Vue d’ensemble des tarifs des machines virtuelles spot
Vous pouvez également interroger l’API des prix de vente au détail Azure pour obtenir programmatiquement la tarification au comptant de toute référence SKU qui vous intéresse.
Comprendre les charges de travail interruptibles
Les charges de travail interruptibles sont les meilleurs cas d’usage pour les machines virtuelles spot. Les charges de travail interruptibles présentent quelques caractéristiques communes. Elles ont des contraintes de temps minimales ou nulles, une faible priorité organisationnelle, et des temps de traitement courts. Elles exécutent des processus qui peuvent s’arrêter soudainement et reprendre ultérieurement sans nuire aux processus organisationnels essentiels. Les applications de traitement par lots, l’analytique des données et les charges de travail qui créent un agent de déploiement continu-intégration continue pour un environnement hors production sont des exemples de charges de travail interruptibles. Ces fonctionnalités contrastent avec les charges de travail ordinaires ou critiques, qui ont des contrats de niveau de service (SLA), des sessions persistantes et des données avec état. Le tableau suivant fournit des exemples pour les deux types de charge de travail.
| Fonctionnalités des charges de travail interruptibles | Fonctionnalités des charges de travail ordinaires | |
|---|---|---|
| Caractéristiques | Peu ou pas de contraintes de temps Faible priorité organisationnelle Temps de traitement courts |
Contrats de niveau de service (SLA) Besoin de sessions persistantes Charges de travail avec état |
Vous pouvez utiliser des machines virtuelles spot dans des charges de travail non interruptibles, mais elles ne doivent pas être la seule source de capacité de calcul. Utilisez autant de machines virtuelles ordinaires que nécessaire pour répondre à vos besoins en matière de durée de bon fonctionnement.
Comprendre l’éviction
Les machines virtuelles spot n’ont aucun contrat de niveau de service (SLA) après leur création et peuvent perdre leur accès au calcul à tout moment. Nous appelons éviction cette perte de calcul. L’offre et la demande de calcul pilotent l’éviction. Quand la demande d’une taille de machine virtuelle spécifique dépasse un certain niveau, Azure rejette les machines virtuelles spot pour mettre le calcul à la disposition des machines virtuelles ordinaires. La demande est propre à l’emplacement. Une augmentation de la demande dans la région A n’affecte pas les machines virtuelles spot situées dans la région B.
Les machines virtuelles spot ont deux options de configuration qui affectent l’éviction. Ces configurations sont le « type d’éviction » et la « stratégie d’éviction » de la machine virtuelle spot. Vous définissez ces configurations lorsque vous créez la machine virtuelle spot. Le « type d’éviction » définit les conditions d’une éviction. La « stratégie d’éviction » détermine ce que l’éviction fait à votre machine virtuelle spot. Intéressons-nous aux deux choix de configuration.
Type d’éviction
L’éviction est due à des changements de capacité ou de prix. La façon dont ces changements affectent les machines virtuelles spot dépend du type d’éviction choisi lors de la création de la machine virtuelle. Le type d’éviction définit les conditions d’une éviction. Les types d’éviction sont « éviction par capacité uniquement » et « éviction par prix ou capacité ».
Éviction par capacité uniquement : ce type d’éviction déclenche une éviction lorsque la capacité de calcul excédentaire disparaît. Par défaut, le prix est plafonné au taux du paiement à l’utilisation. Utilisez ce type d’éviction lorsque vous êtes prêt à payer jusqu’au prix de la machine virtuelle avec paiement à l’utilisation.
Éviction par prix ou capacité : ce type d’éviction a deux déclencheurs. Azure supprime une machine virtuelle spot lorsque la capacité de calcul excédentaire disparaît ou que le coût de la machine virtuelle dépasse le prix maximal que vous avez défini. Ce type d’éviction vous permet de définir un prix maximal bien inférieur au prix du paiement à l’utilisation. Utilisez ce type d’éviction pour définir votre propre plafond de prix.
Stratégie d’éviction
La stratégie d’éviction choisie pour une machine virtuelle spot affecte son orchestration. Par orchestration, nous entendons le processus de gestion d’une éviction. Nous aborderons l’orchestration en détail un peu plus tard. Les stratégies d’éviction sont « Arrêter/Libérer » et « Supprimer ».
Stratégie Arrêter/Libérer : la stratégie d’éviction Arrêter/Libérer est idéale lorsque la charge de travail peut patienter jusqu’à la libération de capacité dans la même localisation et pour le même type de machine virtuelle. La stratégie Arrêter/Libérer arrête la machine virtuelle et met fin à son bail avec le matériel sous-jacent. L’arrêt et la libération d’une machine virtuelle spot sont identiques à l’arrêt et à la libération d’une machine virtuelle normale. La machine virtuelle reste accessible dans Azure, et vous pouvez redémarrer la même machine virtuelle ultérieurement. Avec la stratégie Arrêter/Libérer, la machine virtuelle perd la capacité de calcul et les adresses IP non statiques. Toutefois, les disques de données de machine virtuelle demeurent et entraînent toujours des frais. La machine virtuelle occupe également des cœurs dans l’abonnement. Les machines virtuelles ne peuvent pas être déplacées hors de leur région ou zone, même si elles sont arrêtées/libérées. Pour plus d’informations, consultez États d’alimentation et facturation des machines virtuelles.
Stratégie Supprimer : utilisez la stratégie « Supprimer » si la charge de travail peut changer de localisation ou de taille de machine virtuelle. Le changement de localisation et/ou de taille de machine virtuelle permet à la machine virtuelle de se redéployer plus rapidement. La stratégie Supprimer supprime la machine virtuelle et tout disque de données. La machine virtuelle n’occupe pas de cœurs dans les abonnements. Pour plus d’informations sur les stratégies d’éviction, consultez Stratégie d’éviction.
Concevoir une orchestration flexible
L’orchestration est le processus de remplacement d’une machine virtuelle spot après une éviction. Il s’agit de la base de la création d’une charge de travail interruptible de manière fiable. Un bon système d’orchestration offre une flexibilité intégrée. Par flexibilité, nous entendons concevoir votre orchestration pour avoir des options, utiliser plusieurs tailles de machine virtuelle, déployer dans différentes régions, prendre en compte les évictions et tenir compte de différents scénarios d’éviction pour améliorer la fiabilité et la vitesse des charges de travail.
Vous trouverez ci-dessous des recommandations pour vous aider à concevoir une orchestration flexible pour votre charge de travail interruptible.
Concevoir pour la vitesse
Pour une charge de travail exécutée sur des machines virtuelles spot, la capacité de calcul est un trésor. Le risque imminent d’éviction doit augmenter votre appréciation du temps de calcul alloué, et se traduire par des décisions de conception significatives qui accordent une priorité à la vitesse de la charge de travail. En général, nous vous recommandons d’optimiser le temps de calcul dont vous disposez. Vous devez créer une image de machine virtuelle avec tous les logiciels requis préinstallés. Les logiciels préinstallés permettent de réduire le délai entre l’éviction et l’exécution complète d’une application. Vous devez éviter d’utiliser le temps de calcul sur des processus qui ne contribuent pas à l’objectif de la charge de travail. Une charge de travail pour l’analytique données, par exemple, doit concentrer le plus de temps de calcul sur le traitement des données, et le moins possible sur la collecte des métadonnées d’éviction. Éliminez les processus non essentiels de votre application.
Utiliser plusieurs tailles de machines virtuelles et localisations
Nous vous recommandons de créer une orchestration pour utiliser plusieurs types et tailles de machines virtuelles afin d’accroître la flexibilité. L’objectif est de donner à votre orchestration des options pour remplacer une machine virtuelle supprimée. Azure a différents types et tailles de machines virtuelles qui fournissent des fonctionnalités similaires pour à peu près le même prix. Vous devez filtrer les machines virtuelles à la quantité minimale de processeurs/cœurs virtuels et/ou de RAM, et au prix maximal afin de trouver plusieurs machines virtuelles qui ont les moyens d’exécuter votre charge de travail et de s’adapter à votre budget. Chaque type de machine virtuelle a un taux d’éviction exprimé en pourcentage (0-5 %, 5-10 %, 10-15 %, 15-20 %, + de 20 %). Les taux d’éviction peuvent varier d’une région à l’autre. Vous pouvez trouver un meilleur taux d’éviction pour le même type de machine virtuelle dans une autre région. Vous trouverez les taux d’éviction pour chaque type de machine virtuelle dans le portail sous l’onglet « Informations de base ». Sélectionnez les liens « Taille » (« Afficher l’historique des tarifs » ou « Afficher toutes les tailles »). Vous pouvez également obtenir les données de machine virtuelle spot par programmation à l’aide d’Azure Resource Graph. Pour plus d'informations, consultez les pages suivantes :
Utiliser la stratégie d’éviction la plus flexible
La stratégie d’éviction de la machine virtuelle spot supprimée affecte le processus de remplacement. Une stratégie d’éviction Supprimer est plus flexible qu’une stratégie d’éviction Arrêter/Libérer.
Considérez d’abord la stratégie Supprimer : nous vous recommandons d’utiliser une stratégie d’éviction Supprimer si votre charge de travail peut la gérer. La suppression permet à l’orchestration de déployer des machines virtuelles spot de remplacement dans de nouvelles zones et régions. Cette flexibilité de déploiement peut aider votre charge de travail à trouver une capacité de calcul de rechange plus rapidement qu’une machine virtuelle arrêtée/libérée. Les machines virtuelles arrêtées/libérées doivent attendre qu’une capacité de calcul soit disponible dans la zone dans laquelle elles ont été créées. Pour la stratégie de suppression, vous aurez besoin d’un processus pour surveiller les évictions externes à l’application et orchestrer les déploiements dans différentes régions et/ou avec différentes références SKU de machine virtuelle.
Comprendre la stratégie Arrêter/Libérer : la stratégie Arrêter/Libérer offre moins de flexibilité que la stratégie Supprimer. Les machines virtuelles spot doivent rester dans la même région et la même zone. Vous ne pouvez pas déplacer une machine virtuelle arrêtée/libérée vers une autre localisation. Étant donné que les machines virtuelles ont une localisation fixe, vous aurez besoin que quelque chose soit en place pour réallouer la machine virtuelle lorsque de la capacité de calcul sera disponible. Il n’existe aucun moyen de prédire quand la capacité de calcul sera disponible. Nous vous recommandons donc d’utiliser un pipeline de planification automatisé pour tenter un redéploiement après une éviction. Une éviction doit déclencher le pipeline de planification, et les tentatives de redéploiement doivent vérifier en permanence la disponibilité de la capacité de calcul jusqu’à ce qu’elle soit disponible.
| Policy | Lorsque le répertoire | |
|---|---|---|
| DELETE | Calcul et données éphémères Vous ne voulez pas payer pour les disques de données Budget minimal |
|
| Arrêter/Libérer | Vous avez besoin d’une taille de machine virtuelle spécifique Impossible de changer la localisation Processus d’installation d’application long |
Temps d’attente indéfini Non motivé uniquement par les économies de coûts |
Superviser en permanence l’éviction
La supervision est la clé de la fiabilité de la charge de travail sur les machines virtuelles spot. Les machines virtuelles spot n’ont pas de contrat SLA après leur création, et elles peuvent être supprimées à tout moment. La meilleure façon d’améliorer la fiabilité de la charge de travail sur les machines virtuelles spot consiste à anticiper le moment où elles seront évincées. Avec ces informations, vous pouvez tenter un arrêt approprié de la charge de travail et déclencher l’automatisation qui orchestre le remplacement.
Utiliser Scheduled Events : nous vous recommandons d’utiliser le service Scheduled Events pour chaque machine virtuelle. Azure envoie des signaux aux machines virtuelles qu’elles vont être affectées par la maintenance de l’infrastructure. Les évictions rentrent dans le cadre de la maintenance d’infrastructure. Azure envoie le signal Preempt à toutes les machines virtuelles au moins 30 secondes avant leur éviction. Un service appelé Schedule Events vous permet de capturer ce signal Preempt en interrogeant un point de terminaison à une adresse IP statique et non routable 169.254.169.254.
Utiliser des requêtes fréquentes : nous vous recommandons d’interroger le point de terminaison Schedule Events assez souvent pour orchestrer un arrêt approprié. Vous pouvez interroger le point de terminaison Scheduled Events toutes les secondes, mais une telle fréquence n’est pas forcément nécessaire dans certains cas d’usage. Ces requêtes doivent provenir d’une application s’exécutant sur la machine virtuelle spot. La requête ne peut pas provenir d’une source externe. Par conséquent, les requêtes consomment de la capacité de calcul de machine virtuelle et dérobent de la puissance de traitement à la charge de travail principale. Vous devrez trouver un équilibre entre ces priorités concurrentes afin de répondre aux exigences de votre situation spécifique.
Automatiser l’orchestration : une fois que vous avez collecté le signal Preempt, votre orchestration doit agir sur ce signal. Étant donné les contraintes de temps, le signal Preempt doit tenter un arrêt approprié de votre charge de travail et démarrer un processus automatisé qui remplace la machine virtuelle spot. Pour plus d'informations, consultez les pages suivantes :
Créer un système de déploiement
Votre orchestration a besoin d’un pipeline automatisé pour déployer de nouvelles machines virtuelles spot lorsqu’elles sont évincées. Le pipeline doit s’exécuter en dehors de la charge de travail interruptible elle-même afin de garantir la permanence. Le fonctionnement du pipeline de déploiement dépendra de la stratégie d’éviction que vous avez sélectionnée pour vos machines virtuelles spot.
Pour une stratégie Supprimer, nous vous recommandons de créer un pipeline qui utilise différentes tailles de machines virtuelles et déploie dans différentes régions. Pour une stratégie Arrêter/Libérer, le pipeline de déploiement a besoin de deux actions distinctes. Pour la création initiale d’une machine virtuelle, le pipeline doit déployer les machines virtuelles de taille appropriée dans la localisation appropriée. Pour une machine virtuelle évincée, le pipeline doit essayer de redémarrer la machine virtuelle jusqu’à ce que l’opération aboutisse. Une combinaison d’alertes Azure Monitor et d’Azure Functions est l’une des nombreuses façons d’automatiser un système de déploiement. Le pipeline peut utiliser des modèles bicep. Ils sont déclaratifs et idempotents, et représentent une bonne pratique pour le déploiement de l’infrastructure.
Préparer une éviction immédiate
Il est possible que votre machine virtuelle spot soit désignée pour éviction dès sa création et avant même l’exécution de votre charge de travail. Le simple fait qu’il y avait de la capacité pour créer une machine virtuelle spot ne signifie pas qu’elle persistera. Les machines virtuelles spot n’ont aucune garantie de disponibilité (SLA) après leur création. Votre orchestration doit prendre en compte les évictions immédiates. Le signal Preempt fournira toujours un préavis d’au moins 30 secondes avant l’éviction.
Nous vous recommandons d’incorporer des contrôles d’intégrité des machines virtuelles dans votre orchestration pour préparer les évictions immédiates. L’orchestration pour les évictions immédiates ne peut pas s’appuyer sur le signal Preempt d’Scheduled Events. Seule la machine virtuelle elle-même peut interroger le signal Preempt, et il n’y a pas suffisamment de temps pour démarrer une application, interroger le point de terminaison Scheduled Events et s’arrêter de manière appropriée. Le contrôle d’intégrité doit donc résider en dehors de l’environnement de charge de travail. Les contrôles d’intégrité doivent surveiller l’état de la machine virtuelle spot, et démarrer le pipeline de déploiement pour remplacer la machine virtuelle spot lorsque son état bascule sur « libérée » ou « arrêtée ».
Planifier plusieurs évictions simultanées
Si vous exécutez un cluster de machines virtuelles spot, vous devez concevoir la charge de travail de façon à ce qu’elle résiste à plusieurs évictions simultanées. Plusieurs machines virtuelles spot dans la charge de travail pourraient être supprimées en même temps. Une éviction simultanée de plusieurs machines virtuelles peut affecter le débit de l’application. Pour éviter cette situation, votre pipeline de déploiement doit être en mesure de collecter les signaux de plusieurs machines virtuelles et de déployer plusieurs machines virtuelles de remplacement simultanément.
Concevoir un arrêt approprié
Les processus d’arrêt de machine virtuelle doivent être inférieurs à 30 secondes, et permettre à votre machine virtuelle de s’arrêter avant une éviction. La durée nécessaire à l’arrêt dépend de la fréquence à laquelle votre charge de travail interroge le point de terminaison Scheduled Events. Plus vous interrogez souvent le point de terminaison, plus le processus d’arrêt peut être long. Le processus d’arrêt doit libérer les ressources, vider les connexions et vider les journaux des événements. Vous devez régulièrement créer et enregistrer des points de contrôle pour enregistrer le contexte et créer une stratégie de récupération plus efficace. Le point de contrôle est simplement constitué d’informations sur les processus ou les transactions sur lesquels la machine virtuelle suivante doit démarrer. Ils doivent indiquer si la machine virtuelle doit reprendre là où la précédente s’est arrêtée, ou si la nouvelle machine virtuelle doit annuler les modifications et redémarrer l’ensemble du processus. Vous devez stocker les points de contrôle en dehors de l’environnement de machine virtuelle spot. Un compte de stockage serait adéquat.
Tester l’orchestration
Nous vous recommandons de simuler des événements d’éviction afin de tester l’orchestration dans des environnements de développement/test. Pour plus d’informations, consultez Simuler l’éviction.
Concevoir une charge de travail idempotente
Nous vous recommandons de concevoir une charge de travail idempotente. Le résultat du traitement d’un événement à plusieurs reprises doit être identique à son traitement une seule fois. Les évictions peuvent entraîner des arrêts forcés en dépit des efforts déployés pour garantir des arrêts appropriés. Les arrêts forcés peuvent arrêter les processus avant leur achèvement. Les charges de travail idempotentes peuvent recevoir le même message à plusieurs reprises et le résultat reste le même. Pour plus d’informations, consultez Idempotence.
Utiliser une période de préchauffage de l’application
La plupart des charges de travail interruptibles exécutent des applications. Les applications ont besoin de temps pour s’installer et démarrer. Elles ont besoin de temps pour se connecter au stockage externe et collecter des informations à partir des points de contrôle. Nous vous recommandons de faire en sorte qu’il y ait une période de préchauffage de l’application avant de l’autoriser à commencer le traitement. Pendant la période de préchauffage, l’application doit démarrer, se connecter et se préparer à contribuer. Vous ne devez autoriser une application à commencer à traiter des données qu’une fois que vous avez validé son intégrité.
Configurer des identités managées affectées par l’utilisateur
Nous vous recommandons d’utiliser des identités managées affectées par l’utilisateur pour simplifier le processus d’authentification et d’autorisation. Les identités managées affectées par l’utilisateur permettent d’éviter de mettre des informations d’identification dans le code. Contrairement aux identités managées affectées par le système, elles ne sont pas liées à une ressource unique. Les identités managées affectées par l’utilisateur contiennent des autorisations et des jetons d’accès de Microsoft Entra ID qui peuvent être réutilisés et affectés à des machines virtuelles spot pendant l’orchestration. La cohérence des jetons parmi les machines virtuelles spot permet de simplifier l’orchestration et l’accès aux ressources de charge de travail dont dispose les machines virtuelles spot.
Avec les identités managées affectées par le système, une nouvelle machine virtuelle spot peut obtenir un jeton d’accès différent à partir de Microsoft Entra ID. Si vous devez utiliser des identités managées affectées par le système, nous vous recommandons de rendre les charges de travail résilientes aux réponses 403 Forbidden Error. Votre orchestration devra obtenir des jetons à partir de Microsoft Entra ID avec les autorisations appropriées. Pour plus d’informations, voir Identités managées.
Exemple de scénario
L’exemple de scénario déploie une application de traitement de file d’attente qui remplit les critères de charge de travail interruptible. Les scripts du scénario sont illustratifs. Le scénario vous guide tout au long d’une poussée manuelle unique pour déployer des ressources. Nous n’avons pas fourni de pipeline de déploiement avec cette implémentation. Toutefois, un pipeline de déploiement est essentiel pour automatiser le processus d’orchestration. Le diagramme illustre l’architecture de l’exemple de scénario.
Les notes suivantes expliquent les principaux aspects de l’architecture :
- Définition d’application de machine virtuelle : la définition d’application de machine virtuelle est créée dans Azure Compute Gallery. Elle définit le nom de l’application, la localisation, le système d’exploitation et les métadonnées. La version de l’application est une version numérotée de la définition de l’application de machine virtuelle. La version de l’application est une instanciation de l’application de machine virtuelle. Elle doit se trouver dans la même région que la machine virtuelle spot. La version de l’application est liée au package d’application source dans le compte de stockage.
- Compte de stockage : le compte de stockage stocke le package d’application source. Dans cette architecture, il s’agit d’un fichier tar compressé nommé
worker-0.1.0.tar.gz. Il contient deux fichiers. L’un d’eux est le script bashorchestrate.shqui installe l’application Worker .NET. - Machine virtuelle spot : la machine virtuelle spot est déployée. Elle doit se trouver dans la même région que la version de l’application. Elle télécharge
worker-0.1.0.tar.gzsur la machine virtuelle après le déploiement. Le modèle bicep déploie une image Ubuntu sur une machine virtuelle de la famille Standard. Ces configurations répondent aux besoins de cette application, et ne sont pas des recommandations générales pour vos applications. - File d’attente de stockage : l’autre service en cours d’exécution dans le Worker .NET contient la logique de file d’attente des messages. Microsoft Entra ID accorde à la machine virtuelle spot l’accès à la file d’attente de stockage avec une identité affectée par l’utilisateur à l’aide de RBAC.
- Application Worker .Net : le script orchestrate.sh installe une application Worker .NET qui exécute deux services d’arrière-plan. Le premier service interroge le point de terminaison Scheduled Events, recherche le signal
Preemptet envoie ce signal au deuxième service. Le deuxième service traite les messages de la file d’attente de stockage et écoute le signalPreemptdu premier service. Lorsque le deuxième service reçoit le signal, il interrompt le traitement de la file d’attente de stockage et commence l’arrêt. - Interroger le point de terminaison Scheduled Events : une requête d’API est envoyée à une adresse IP statique non routable 169.254.169.254. La requête d’API interroge le point de terminaison Scheduled Events afin de détecter les signaux de maintenance de l’infrastructure.
- Application Insights : l’architecture utilise Application Insights uniquement à des fins d’apprentissage. Il ne s’agit pas d’un composant essentiel de l’orchestration des charges de travail interruptibles. Nous l’avons inclus pour vous permettre de valider la télémétrie de l’application Worker .NET. Nous avons configuré l’application Worker .NET de façon à envoyer la télémétrie à Application Insights. Pour plus d’informations, consultez Activer les métriques temps réel à partir d’une application .NET.
Déployer ce scénario
Nous avons créé un dépôt GitHub nommé interruptible workload on spot, contenant des modèles, des scripts et des instructions pas à pas pour déployer cette architecture. Vous trouverez plus de détails techniques sur l’architecture et les artefacts d’ingénierie dans ce dépôt.
Étape suivante
Pour plus d’informations sur les machines virtuelles spot, consultez Machines Virtuelles Azure Spot.