Dans cet article, nous décrivons les meilleures pratiques de création sur des machines virtuelles Spot Azure et incluons un exemple de scénario déployable. Les machines virtuelles Spot offrent l’accès à la capacité de calcul à des remises significatives aux machines virtuelles régulières. Cette remise les rend attrayantes pour les organisations qui cherchent à optimiser les coûts, mais les économies sont associées à une condition. Les machines virtuelles Spot peuvent perdre l’accès au calcul à tout moment. Nous appelons ce processus une éviction. Les charges de travail exécutées sur des machines virtuelles spot doivent être en mesure de gérer ces interruptions dans le calcul. La charge de travail appropriée et un mécanisme d’orchestration flexible sont les clés du succès. Voici nos recommandations pour la création de machines virtuelles spot.
Comprendre les machines virtuelles spot
Au niveau technique, les machines virtuelles spot sont identiques aux machines virtuelles régulières. Ils utilisent les mêmes images, matériels et disques qui se traduisent par les mêmes performances. La différence entre les machines virtuelles spot et les machines virtuelles régulières est en priorité et en 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 l’accès à cette capacité de calcul. Examinons plus en détail la priorité et la disponibilité.
Aucun accès prioritaire. Les machines virtuelles régulières ont un accès prioritaire à la capacité de calcul. Ils accèdent à la capacité de calcul chaque fois qu’ils le demandent. Les machines virtuelles Spot, d’autre part, ne déploient que lorsqu’il existe une capacité de calcul de rechange et qu’elles restent en cours d’exécution uniquement lorsqu’une machine virtuelle normale n’a pas besoin du matériel sous-jacent.
Aucune garantie de disponibilité. Les machines virtuelles Spot n’ont aucune garantie de disponibilité. Ils n’ont pas de contrats 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 supprime la machine virtuelle spot. Azure fournit un préavis de 30 secondes minimum avant l’éviction réelle. Pour plus d’informations, consultez surveiller en permanence l’éviction dans cet article.
Comprendre la tarification des machines virtuelles spot
Les machines virtuelles Spot peuvent être jusqu’à 90 % moins chères que les machines virtuelles standard (paiement à l’utilisation). La remise varie en fonction de la demande, de la taille de machine virtuelle, de la région du 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 de coûts. Pour plus d’informations, consultez :
- outil de tarification des machines virtuelles Azure Spot
- Vue d’ensemble des tarifs des machines virtuelles Spot
Vous pouvez également interroger l’API prix de vente au détail Azure pour obtenir par programme la tarification spot pour toute référence SKU d’intérêt.
Comprendre les charges de travail interromptables
Les charges de travail interromptables sont le meilleur cas d’usage pour les machines virtuelles spot. Les charges de travail interromptables présentent quelques caractéristiques courantes. Ils n’ont pas de contraintes de temps minimales, une faible priorité organisationnelle et des temps de traitement courts. Ils exécutent des processus qui peuvent s’arrêter soudainement et reprendre ultérieurement sans nuire aux processus organisationnels essentiels. Des exemples de charges de travail interromptables sont des applications de traitement par lots, l’analytique des données et les charges de travail qui créent un agent de déploiement continu d’intégration continue pour un environnement hors production. Ces fonctionnalités contrastent avec les charges de travail régulières ou critiques qui ont des contrats de niveau de service (SLA), des sessions sticky et des données avec état. Le tableau fournit des exemples pour les deux types de charge de travail.
Fonctionnalités de charge de travail interromptables | Fonctionnalités de charge de travail régulières | |
---|---|---|
fonctionnalités | Contraintes de temps minimales et sans contraintes de temps Priorité organisationnelle faible Temps de traitement courts |
Contrats de niveau de service (SLA) Conditions requises pour les sessions collantes Charges de travail avec état |
Vous pouvez utiliser une machine virtuelle spot dans des charges de travail non interruptions, mais elles ne doivent pas être la seule source de capacité de calcul. Utilisez autant de machines virtuelles régulières que nécessaire pour répondre à vos besoins en temps d’activité.
Comprendre l’éviction
Les machines virtuelles Spot n’ont aucun contrat de niveau de service (SLA) après leur création et peuvent perdre l’accès au calcul à tout moment. Nous appelons cette perte de calcul une éviction. L’offre de calcul et l’éviction des lecteurs de demande. Lorsque la demande d’une taille de machine virtuelle spécifique dépasse un certain niveau, Azure supprime les machines virtuelles spot pour rendre le calcul disponible pour les machines virtuelles régulières. La demande est spécifique à l’emplacement. Une augmentation de la demande dans la région A n’affecte pas les machines virtuelles spot 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 fait l’éviction sur votre machine virtuelle spot. Nous allons aborder les deux choix de configuration.
Type d’éviction
Les changements de capacité ou les changements de prix entraînent des évictions. La façon dont les modifications de capacité et de prix 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 de capacité uniquement » et « prix ou éviction de capacité ».
l’éviction de capacité uniquement: ce type d’éviction déclenche une éviction lorsque l’excès de capacité de calcul disparaît. Par défaut, le prix est limité au tarif de paiement à l’utilisation. Utilisez ce type d’éviction lorsque vous êtes prêt à payer jusqu’au prix de la machine virtuelle de paiement à l’utilisation.
Prix ou éviction de capacité: ce type d’éviction a deux déclencheurs. Azure supprime une machine virtuelle spot lorsque l’excès de capacité de calcul disparaît ou que le coût de la machine virtuelle dépasse le prix maximal que vous définissez. Ce type d’éviction vous permet de définir un prix maximal bien inférieur au prix de paiement à l’utilisation. Utilisez ce type d’éviction pour définir votre propre limite 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 abordons en détail l’orchestration plus loin. Les stratégies d’éviction sont la stratégie « Arrêter/libérer » et « Supprimer la stratégie ».
stratégie d’arrêt/désallouer: la stratégie d’éviction stop/désallouer est optimale lorsque la charge de travail peut attendre la capacité de mise en production dans le même emplacement et le même type de machine virtuelle. La stratégie Stop/Deallocate arrête la machine virtuelle et termine son bail avec le matériel sous-jacent. L’arrêt et la désaffectation d’une machine virtuelle spot sont les mêmes que l’arrêt et l’allocation 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 Stop/Deallocate, la machine virtuelle perd la capacité de calcul et les adresses IP non statiques. Toutefois, les disques de données de machine virtuelle restent 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 de leur région ou de leur zone, même lorsqu’elles sont arrêtées/libérées. Pour plus d’informations, consultez états d’alimentation des machines virtuelles etde facturation.
Supprimer la stratégie: utilisez la stratégie « Supprimer » si la charge de travail peut modifier l’emplacement ou la taille de machine virtuelle. La modification de l’emplacement et/ou de la taille de machine virtuelle permet au machine virtuelle de 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.
Conception pour l’orchestration flexible
L’orchestration est le processus de remplacement d’une machine virtuelle spot après une éviction. C’est la base de la création d’une charge de travail interromptable 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, être conscients de l’éviction et tenir compte des différents scénarios d’éviction pour améliorer la fiabilité et la vitesse de la charge de travail.
Conception 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 élever votre appréciation du temps de calcul alloué et doit se traduire par des décisions de conception significatives qui hiérarchisent la vitesse de charge de travail. En général, vous devez 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. Le logiciel préinstallé permet de réduire le temps entre l’éviction et une application entièrement en cours d’exécution. Vous souhaitez éviter d’utiliser le temps de calcul sur les processus qui ne contribuent pas à l’objectif de la charge de travail. Une charge de travail pour l’analytique des données, par exemple, doit concentrer la plupart du 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 et emplacements de machine virtuelle
Nous vous recommandons de créer une orchestration pour utiliser plusieurs types de machines virtuelles et tailles pour accroître la flexibilité. L’objectif est de donner à vos options d’orchestration de remplacer une machine virtuelle supprimée. Azure a différents types de machines virtuelles et tailles qui fournissent des fonctionnalités similaires pour environ le même prix. Vous devez filtrer les machines virtuelles min vCPUs/Cores et/ou min RAM, et le prix maximal pour rechercher plusieurs machines virtuelles qui ont la puissance d’exécuter votre charge de travail et s’adapter à votre budget.
Chaque type de machine virtuelle a un taux d’éviction exprimé sous la forme d’une plage de pourcentage (0-5%, 5-10%, 10-15%, 15-20%, 20+%). Les taux d’éviction peuvent varier entre les régions. Vous trouverez peut-être 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 prix » ou « Afficher toutes les tailles »). Vous pouvez également obtenir par programme des données de machine virtuelle spot à l’aide d’Azure Resource Graph.
En outre, envisagez d’utiliser le score de placement Spot de fonctionnalité pour évaluer la probabilité de réussite des déploiements Spot individuels dans le cadre de votre système d’orchestration. Pour plus d’informations, consultez :
- taux d’éviction
- Azure Resource Graph
- score de positionnement spot (préversion)
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 de suppression est plus flexible qu’une stratégie d’éviction arrêtée/libérée.
Envisagez d’abord la stratégie de suppression: nous vous recommandons d’utiliser une stratégie d’éviction 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 rapide qu’une machine virtuelle arrêtée/désallouée. Les machines virtuelles arrêtées/libérées doivent attendre la capacité de calcul de rechange dans la même zone dans laquelle elle a été créée. Pour la stratégie de suppression, vous avez besoin d’un processus pour surveiller les évictions externes à l’application et orchestre 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êtée/désalloué: la stratégie arrêtée/désalloué a moins de flexibilité que la stratégie de suppression. 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/désallouée vers un autre emplacement. Étant donné que les machines virtuelles ont un emplacement fixe, vous avez besoin d’un élément en place pour réallouer la machine virtuelle lorsque la capacité de calcul devient disponible. Il n’existe aucun moyen de prédire la disponibilité de la capacité de calcul. Vous devez donc utiliser un pipeline de planification automatisée 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 capacité de calcul jusqu’à ce qu’elle soit disponible.
Politique | Quand | |
---|---|---|
Supprimer | Calcul et données éphémères Ne souhaitez pas payer pour les disques de données Budget minimal |
|
Arrêté/désalloué | Besoin d’une taille de machine virtuelle spécifique Impossible de modifier l’emplacement Processus d’installation long de l’application |
Temps d’attente indéfini Non pilotée par les économies de coûts seules |
Surveiller en permanence l’éviction
La surveillance est la clé de la fiabilité de la charge de travail sur les machines virtuelles spot. Les machines virtuelles Spot n’ont aucun contrat SLA après la création et 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 quand elles seront supprimées. Avec ces informations, vous pouvez tenter un arrêt normal de la charge de travail et déclencher l’automatisation qui orchestre le remplacement.
utiliser des événements planifiés: utilisez le service Événements planifiés pour chaque machine virtuelle. Azure envoie des signaux aux machines virtuelles lorsque la maintenance de l’infrastructure va les affecter. Les évictions sont qualifiées de maintenance de l’infrastructure. Azure envoie le signal Preempt
à toutes les machines virtuelles au minimum 30 secondes avant qu’elles ne soient supprimées. Un service appelé Événements de planification vous permet de capturer ce signal Preempt
en interrogeant un point de terminaison sur une adresse IP statique et non routable 169.254.169.254
.
Utiliser des requêtes fréquentes: interroger le point de terminaison d’événements de planification suffisamment souvent pour orchestrer un arrêt approprié. Vous pouvez interroger le point de terminaison Des événements planifiés jusqu’à chaque seconde, mais une seconde fréquence peut ne pas être nécessaire pour tous les 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 la capacité de calcul des machines virtuelles et volent la puissance de traitement de la charge de travail principale. Vous devez équilibrer ces priorités concurrentes pour répondre à votre situation spécifique.
Automatiser l’orchestration: une fois que vous collectez le signal Preempt
, votre orchestration doit agir sur ce signal. Étant donné les contraintes de temps, le signal Preempt
doit tenter un arrêt normal de votre charge de travail et démarrer un processus automatisé qui remplace la machine virtuelle spot. Pour plus d’informations, consultez :
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 supprimées. Le pipeline doit s’exécuter en dehors de la charge de travail interromptable elle-même pour garantir la permanence. La façon dont le pipeline de déploiement doit fonctionner dépend de la stratégie d’éviction que vous sélectionnez pour vos machines virtuelles spot.
Pour une stratégie de suppression, nous vous recommandons de créer un pipeline qui utilise différentes tailles de machine virtuelle et des déploiements dans différentes régions. Pour une stratégie stop/désalloué, 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 à l’emplacement approprié. Pour une machine virtuelle supprimée, le pipeline doit essayer de redémarrer la machine virtuelle jusqu’à ce qu’elle fonctionne. Une combinaison d’alertes Azure Monitor et d’Azure Functions est l’une des différentes 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 d’infrastructure.
Préparer l’éviction immédiate
Il est possible qu’Azure supprime une machine virtuelle spot dès que vous la créez et avant l’exécution de votre charge de travail. Tout simplement parce qu’il y avait une capacité à créer une machine virtuelle spot, cela ne signifie pas qu’elle persiste. Les machines virtuelles Spot n’ont aucune garantie de disponibilité (SLA) après la création. Votre orchestration doit tenir compte des évictions immédiates. Le signal Preempt
fournit un préavis de 30 secondes minimum de l’éviction.
Incorporez 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 les événements de planification Preempt
signal. 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 d’événements de planification et arrêter correctement. Par conséquent, le contrôle d’intégrité doit résider en dehors de l’environnement de charge de travail. Les vérifications 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 l’état change d’allocation ou d’arrêt.
Planifier plusieurs évictions simultanées
Si vous exécutez un cluster de machines virtuelles spot, vous devez concevoir la charge de travail pour résister à plusieurs évictions simultanées. Plusieurs machines virtuelles spot dans la charge de travail peuvent ê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 des signaux à partir de plusieurs machines virtuelles et de déployer simultanément plusieurs machines virtuelles de remplacement.
Conception d’un arrêt approprié
Les processus d’arrêt de machine virtuelle doivent être inférieurs à 30 secondes et autoriser votre machine virtuelle à s’arrêter avant une éviction. La durée pendant laquelle l’arrêt doit prendre dépend de la fréquence à laquelle votre charge de travail interroge le point de terminaison Événements planifiés. Plus vous interrogez le point de terminaison plus souvent, plus le processus d’arrêt peut être long. Le processus d’arrêt doit libérer des ressources, vider les connexions et vider les journaux des événements. Vous devez créer et enregistrer régulièrement 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 des informations sur les processus ou transactions sur utilisant la machine virtuelle suivante. Ils doivent indiquer si la machine virtuelle doit reprendre l’emplacement où la machine virtuelle précédente est désactivée ou si la nouvelle machine virtuelle doit restaurer 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 fonctionne.
Tester l’orchestration
Nous vous recommandons de simuler des événements d’éviction pour tester l’orchestration dans les 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 fois doit être le même que celui du traitement une seule fois. Les évictions peuvent entraîner des arrêts forcés malgré les efforts visant à garantir des arrêts corrects. Les arrêts forcés peuvent arrêter les processus avant l’achèvement. Les charges de travail idempotentes peuvent recevoir le même message plusieurs fois et le résultat reste le même. Pour plus d’informations, consultez idempotency .
Utiliser une période de préchauffement d’application
La plupart des charges de travail interromptables exécutent des applications. Les applications ont besoin de temps pour l’installation et l’heure de démarrage. Ils ont besoin de temps pour se connecter au stockage externe et collecter des informations à partir de points de contrôle. Nous vous recommandons d’avoir une période de préchauffement de l’application avant de l’autoriser à démarrer le traitement. Pendant la période de préchauffage, l’application doit démarrer, se connecter et se préparer à contribuer. Vous devez autoriser une application à démarrer le traitement des données après avoir validé l’intégrité de l’application.
diagramme
Configurer les 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 placer des informations d’identification dans le code et ne sont pas liées à une seule ressource, comme les identités managées affectées par le système. 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 entre les machines virtuelles spot permet de simplifier l’orchestration et l’accès aux ressources de charge de travail dont disposent 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 de l’ID Microsoft Entra. 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 doit obtenir des jetons de Microsoft Entra ID avec les autorisations appropriées. Pour plus d’informations, consultez identités managées.
Exemple de scénario
L’exemple de scénario déploie une application de traitement de file d’attente qui se qualifie comme une charge de travail interromptable. Les scripts du scénario sont illustrants. Le scénario vous guide tout au long d’une transmission push manuelle unique pour déployer des ressources. Il n’existe pas 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 aspects clés de l’architecture :
- définition d’application de machine virtuelle : La définition de l’application de machine virtuelle est créée dans la galerie de calcul Azure. Il définit le nom, l’emplacement, le système d’exploitation et les métadonnées de l’application. 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. Un fichier est leorchestrate.sh
script bash qui installe l’application worker .NET. -
machine virtuelle Spot : La machine virtuelle spot se déploie. Elle doit se trouver dans la même région que la version de l’application. Il télécharge
worker-0.1.0.tar.gz
sur la machine virtuelle après le déploiement. Le modèle bicep déploie une image Ubuntu sur une machine virtuelle de 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 exécuté dans le worker .NET contient la logique de file d’attente de 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 en arrière-plan. Le premier service interroge le point de terminaison Des événements de planification et recherche le signal
Preempt
et envoie ce signal au deuxième service. Le deuxième service traite les messages de la file d’attente de stockage et écoute le signalPreempt
du premier service. Lorsque le deuxième service reçoit le signal, il interrompt le traitement de la file d’attente de stockage et commence à s’arrêter. - point de terminaison d’événements planifiés de requête : une requête d’API est envoyée à une adresse IP non routable statique 169.254.169.254. La demande d’API interroge le point de terminaison d’événement planifié pour les signaux de maintenance de l’infrastructure.
- Application Insights : L’architecture utilise Application Insights uniquement à des fins d’apprentissage. Ce n’est pas un composant essentiel de l’orchestration de charge de travail interromptable. Il vous permet de valider les données de télémétrie à partir de l’application worker .NET. L’application worker .NET envoie des données de télémétrie à Application Insights. Pour plus d’informations, consultez activer les métriques actives à partir de l’application .NET.
Déployer ce scénario
Il existe un dépôt GitHub appelé charge de travail interromptable sur place avec des modèles, des scripts et des instructions pas à pas pour déployer cette architecture.
Étape suivante
Pour plus d’informations sur les machines virtuelles Spot, consultez machines virtuelles Azure Spot.