Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Pour approvisionner une machine virtuelle dans Azure, vous avez besoin de plus de composants que la machine virtuelle elle-même. Un déploiement complet inclut les ressources de mise en réseau et de stockage. Cet article décrit les meilleures pratiques d’exécution d’une machine virtuelle Linux sécurisée sur Azure.
Architecture
Téléchargez un fichier Visio de cette architecture.
Flux de travail
Cet exemple montre un déploiement de base qui utilise les composants requis pour une seule machine virtuelle. La machine virtuelle peut exécuter des charges de travail et atteindre l’Internet public tout en évitant une exposition directe aux menaces externes. Dans cette architecture :
Les charges de travail sur la machine virtuelle n’ont aucune exposition à Internet directe. L'accès est limité aux ressources situées dans le même réseau virtuel ou dans un réseau virtuel appairé, par exemple dans une configuration hub-and-spoke.
Vous gérez la machine virtuelle à l’aide de Azure Bastion via Secure Shell (SSH). Il n’existe aucun accès direct à partir de l’Internet public vers la machine virtuelle pour la gestion.
La passerelle NAT (Network Address Translation) et son adresse IP publique associée fournissent un accès Internet externe sortant.
Components
Cette architecture utilise les composants suivants.
groupe de ressources
Un groupe resource est un conteneur logique qui contient des ressources Azure associées. Les groupes de ressources vous permettent de déployer, de surveiller et de supprimer des ressources associées ensemble et de suivre leurs coûts en tant qu’unité.
En général, regroupez les ressources par cycle de vie partagé et propriété. Utilisez des noms cohérents et descriptifs pour les ressources afin de faciliter leur identification et leur compréhension. Pour plus d’informations, consultez Définir votre convention de dénomination.
Machine virtuelle
Vous pouvez approvisionner une machine virtuelle à partir d’une liste d’images publiées, d’une image managée personnalisée ou d’un disque dur virtuel chargé sur Stockage Blob Azure. Azure prend en charge les distributions Linux populaires, notamment Debian, Red Hat Enterprise Linux (RHEL) et Ubuntu. Pour plus d’informations, consultez Distributions Linux approuvées.
Azure fournit de nombreuses tailles de machine virtuelle différentes. Si vous déplacez une charge de travail existante vers Azure, commencez par la taille de machine virtuelle qui correspond le plus étroitement à vos serveurs locaux. Après avoir déployé la machine virtuelle, mesurez les performances de votre charge de travail réelle en termes d’opérations de processeur, de mémoire et de sortie d’entrée de disque par seconde (IOPS) et ajustez la taille en fonction des besoins.
Choisissez une région Azure la plus proche de vos utilisateurs internes ou clients. Certaines tailles de machine virtuelle ne sont pas disponibles dans toutes les régions. Pour plus d’informations, consultez zones géographiques Azure. Pour obtenir la liste des tailles de machine virtuelle disponibles dans une région spécifique, exécutez la commande suivante à partir de l’Azure CLI :
az vm list-sizes --location <location>
Pour plus d’informations sur le choix d’une image de machine virtuelle publiée, consultez Rechercher des informations sur les images de la Place de marché Azure.
Disques
Pour obtenir les meilleures performances d’entrée de disque (E/S), nous vous recommandons des disques SSD Premium, qui stockent des données sur des disques SSD (SSD). La capacité du disque provisionné détermine le coût, les IOPS et le débit (taux de transfert de données). Prenez en compte les trois facteurs lorsque vous sélectionnez une taille de disque. Les SSD Premium incluent des pics de performance gratuits, ce qui vous aide à répondre aux pics de demande sans avoir à surprovisionner et à réduire le coût de la capacité inutilisée lorsqu’ils sont associés à une bonne compréhension des profils de charge de travail.
Note
Les disques SSD Premium v2 et Ultra ne peuvent être utilisés que pour les disques de données. Ils ne sont pas pris en charge pour les disques de système d’exploitation.
Les disques gérés simplifient la gestion des disques en s'occupant du stockage à votre place. Les disques gérés ne nécessitent pas de compte de stockage. Il vous suffit simplement de spécifier leur taille et leur type, puis de les déployer en tant que ressource à haute disponibilité. Les disques managés réduisent également les coûts en fournissant les performances dont vous avez besoin sans surprovisionnement, ce qui vous permet d’éviter de payer pour une capacité provisionnée inutilisée.
Par défaut, le disque du système d’exploitation est un disque managé stocké dans Stockage sur disque Azure, de sorte qu’il persiste même lorsque l’ordinateur hôte est arrêté. Pour les charges de travail sans état, où l’approvisionnement rapide et aucune persistance du système d’exploitation n’est souhaitée, utilisez des disques de système d’exploitation éphémères. Ces disques placent l'image du système d'exploitation sur le stockage local de l'hôte de machine virtuelle au lieu de l'stockage Azure à distance, ce qui réduit la latence de lecture, accélère la réinitialisation et élimine le coût du disque managé. Toutefois, toutes les données d'un disque de système d'exploitation éphémère sont perdues lors d'un arrêt (désallocation), d'une recréation d'image ou d'événements de réparation liés à la maintenance de l'hôte. Les disques de système d'exploitation éphémères ne prennent pas en charge les instantanés ou les Sauvegarde Azure. Utilisez des disques de système d’exploitation éphémères uniquement lorsque les machines virtuelles sont entièrement redéployables à partir de l’automatisation.
Par défaut, de nombreuses images Linux ne configurent pas l’espace d’échange. Si votre charge de travail nécessite un échange, créez-la sur le disque temporaire à l’aide de cloud-init plutôt que sur le disque du système d’exploitation ou sur un disque de données.
Nous vous recommandons de créer un ou plusieurs disques de données pour les données d’application. Les disques de données sont des disques managés persistants sauvegardés par stockage.
Lorsque vous créez un disque, il n’est pas mis en forme. Connectez-vous à la machine virtuelle pour mettre en forme le disque. Dans l’interpréteur de commandes Linux, les disques de données sont affichés sous la forme /dev/sdc, /dev/sddet les lettres ultérieures de la série. Vous pouvez exécuter lsblk pour répertorier les périphériques de bloc, y compris les disques. Pour utiliser un disque de données, créez une partition et un système de fichiers, puis montez le disque. Par exemple :
# Create a partition.
sudo fdisk /dev/sdc # Enter 'n' to partition, 'w' to write the change.
# Create a file system.
sudo mkfs -t ext3 /dev/sdc1
# Mount the drive.
sudo mkdir /data1
sudo mount /dev/sdc1 /data1
Lorsque vous ajoutez un disque de données, un numéro d’unité logique (LUN) lui est attribué. Vous pouvez également spécifier l’ID d’unité logique si, par exemple, vous remplacez un disque et souhaitez conserver le même ID d’unité logique, ou si vous disposez d’une application qui recherche un ID d’unité logique spécifique. Toutefois, les identifiants LUN doivent être uniques sur chaque disque.
Pour les disques de stockage Premium, vous souhaiterez peut-être modifier le planificateur d’E/S pour optimiser les performances sur les disques SSD. Une recommandation courante consiste à utiliser le planificateur No Operation (NOOP) pour les disques SSD, mais vous devez utiliser un outil tel que iostat pour surveiller les performances des E/S de disque pour votre charge de travail.
De nombreuses machines virtuelles sont créées avec un disque temporaire, qui est stocké sur un lecteur physique sur l’ordinateur hôte. Il n’est pas enregistré dans le stockage et peut être supprimé pendant les redémarrages et autres événements de cycle de vie des machines virtuelles. N’utilisez ce disque que pour des données temporaires, telles que des fichiers de pagination ou d’échange. Pour les machines virtuelles Linux, le disque temporaire est /dev/disk/azure/resource-part1. Il est monté sur /mnt/resource ou /mnt.
Réseau
Les composants réseau incluent les ressources suivantes :
Réseau virtuel : Chaque machine virtuelle est déployée dans un réseau virtuel qui est segmenté en sous-réseaux.
Carte d’interface réseau (NIC) : La carte réseau connecte la machine virtuelle au réseau virtuel et gère tout le trafic entrant et sortant. Chaque taille de machine virtuelle définit un nombre maximal de cartes réseau.
Adresse IP publique : Une adresse IP publique peut être utilisée pour communiquer avec la machine virtuelle à partir de l’extérieur Azure via SSH. Toutefois, cette option est déconseillée, car il s’agit d’un risque potentiel de sécurité.
Avertissement
Évitez d’attacher une adresse IP publique directement à une machine virtuelle. Ne le faites que dans des circonstances extrêmes et incluez d’autres mesures de sécurité, telles que l’utilisation de groupes de sécurité réseau (NSG) pour filtrer le trafic.
Pour l’accès de gestion à une machine virtuelle, utilisez Azure Bastion pour l’accès SSH basé sur un navigateur, ou connectez-vous en privé via un VPN ou un Azure ExpressRoute.
Cette adresse IP publique peut être dynamique ou statique. Par défaut, elle est dynamique. Réservez une adresse IP statique lorsque vous avez besoin d’une adresse IP fixe qui ne change pas, par exemple si vous devez créer un enregistrement DNS « A » ou ajouter l’adresse IP à une liste sécurisée.
Vous pouvez également créer un nom de domaine complet (FQDN) pour l’adresse IP. Vous pouvez inscrire un enregistrement CNAME dans le DNS qui pointe vers le nom de domaine complet (FQDN). Pour plus d’informations, consultez Créer un nom de domaine complet pour une machine virtuelle.
Groupe de sécurité réseau : Utilisez des groupes de sécurité réseau pour autoriser ou refuser le trafic réseau vers des machines virtuelles et des sous-réseaux. Associez-les aux sous-réseaux ou aux cartes réseau individuelles attachées aux machines virtuelles.
Tous les groupes de sécurité réseau contiennent un ensemble de règles de sécurité par défaut, y compris une règle qui bloque tout le trafic Internet entrant. Vous ne pouvez pas supprimer les règles par défaut, mais vous pouvez les remplacer par d’autres règles. Par exemple, vous pouvez créer des règles qui autorisent le trafic Internet entrant vers des ports spécifiques, tels que le port 443 pour HTTPS.
Passerelle Azure de traduction d’adresses réseau (NAT) :Azure NAT Gateway permet à toutes les instances d’un sous-réseau privé de se connecter à Internet en sortie tout en restant entièrement privées. Seuls les paquets qui arrivent en tant que paquets de réponse à une connexion sortante peuvent passer-through une passerelle NAT. Les connexions entrantes non sollicitées en provenance d'Internet ne sont pas autorisées.
Note
Pour améliorer la sécurité par défaut, l’accès Internet sortant implicite est déconseillé pour tous les nouveaux réseaux virtuels. Vous devez configurer explicitement la connectivité Internet sortante à l’aide d’autres ressources telles que la passerelle NAT, Azure les équilibreurs de charge standard ou les pare-feu. Pour plus d’informations, consultez Accès sortant par défaut dans Azure.
Azure Bastion :Azure Bastion est une solution PaaS (Platform as a Service) entièrement managée qui fournit un accès sécurisé aux machines virtuelles via des adresses IP privées. Avec cette configuration, les machines virtuelles n'ont pas besoin d'une adresse IP publique qui les expose à l'internet, ce qui renforce leur posture de sécurité. Azure Bastion fournit une connectivité RDP (Secure Bureau à distance Protocol) ou SSH à vos machines virtuelles directement via TRANSPORT Layer Security (TLS) à l’aide de différentes méthodes, notamment le portail Azure, ou les clients SSH ou RDP natifs.
Opérations
Cette section traite des pratiques opérationnelles clés pour la gestion d’une machine virtuelle Linux dans Azure.
SSH: Avant de créer une machine virtuelle Linux, générez une paire de clés publique-privée RSA 2048 bits. Utilisez le fichier de clé publique lorsque vous créez la machine virtuelle. Pour plus d’informations, consultez Créer et utiliser une paire de clés publique-privée SSH.
Diagnostics: Activez la surveillance et les diagnostics, notamment les indicateurs d’intégrité de base, les journaux de l’infrastructure de diagnostic et les diagnostics de démarrage. Les diagnostics de démarrage peuvent vous aider à diagnostiquer l’échec de démarrage si votre machine virtuelle passe à un état nonbootable. Stockez les journaux de diagnostic dans un compte de stockage. Un compte de stockage à redondance locale standard est suffisant pour les journaux de diagnostic. Pour plus d’informations, consultez Les meilleures pratiques pour la surveillance et les diagnostics.
Disponibilité :une maintenance planifiée ou un temps d’arrêt non planifié peut affecter votre machine virtuelle. Vous pouvez utiliser les journaux de redémarrage de machine virtuelle pour déterminer si la maintenance planifiée a provoqué un redémarrage de machine virtuelle. Pour une disponibilité plus élevée, déployez plusieurs machines virtuelles dans des zones de disponibilité au sein d’une région. Ce déploiement fournit un contrat de niveau de service (SLA) supérieur. Lorsque les zones de disponibilité ne sont pas prises en charge, les groupes à haute disponibilité peuvent vous aider à protéger contre les défaillances de l’hôte ou les mises à jour de l’hôte. Toutefois, les zones de disponibilité sont l’option recommandée si possible.
Sauvegardes: Pour vous protéger contre la perte accidentelle de données, utilisez le service Sauvegarde Azure pour sauvegarder vos machines virtuelles dans le stockage. Selon la région, vous pouvez utiliser le stockage géoredondant ou le stockage redondant interzone pour les sauvegardes. Sauvegarde Azure fournit des sauvegardes cohérentes avec les applications. Pour les charges de travail sensibles aux performances ou les distributions Linux spécialisées qui ne prennent pas en charge les agents de sauvegarde traditionnels, utilisez la fonctionnalité de sauvegarde cohérente multi-disque sans agent pour automatiser la protection des sauvegardes sans affecter les performances des applications.
Arrêt d’une machine virtuelle : Azure fait une distinction entre les états arrêtés et désalloués. Vous êtes facturé lorsque l'état de la machine virtuelle est Arrêtée, mais pas lorsqu'elle est désallouée. Dans le portail Azure, le bouton Stop désalloue la machine virtuelle. Si vous arrêtez la machine virtuelle via le système d'exploitation alors que vous êtes connecté, elle est arrêtée mais pas désallouée ; vous continuez donc à payer.
Suppression d’une machine virtuelle : Si vous supprimez une machine virtuelle, vous pouvez choisir de supprimer ou de conserver ses disques, ce qui vous permet de conserver les données. Toutefois, vous payez toujours pour les disques. Vous pouvez supprimer des disques managés comme n’importe quelle autre ressource Azure. Pour éviter toute suppression accidentelle, utilisez un verrou de ressource pour verrouiller tout le groupe de ressources ou des ressources individuelles, par exemple une machine virtuelle.
Autres solutions
Groupes de machines virtuelles identiques Azure permettent de répartir les charges de travail entre les nœuds. Les charges de travail critiques pour les opérations métier ne doivent jamais dépendre d’une seule machine virtuelle. Vous pouvez ajouter ou supprimer automatiquement des instances de machine virtuelle en fonction de la demande, et effectuer un scale-out en temps de trafic supérieur ou de mise à l’échelle lorsque le trafic est inférieur pour réduire les coûts.
Azure Load Balancer distribue le trafic entre plusieurs machines virtuelles ou un groupe de machines virtuelles identiques. Il peut également être utilisé comme alternative à une passerelle NAT pour autoriser l’accès à une charge de travail à partir d’Internet tout en prenant en charge l’accès sortant.
Application Gateway fournit des fonctionnalités d’équilibrage de charge aux Azure Load Balancer pour les charges de travail HTTP/HTTPS au sein d’une région Azure.
Pour un déploiement au niveau de l’entreprise, consultez Machines virtuelles Azure architecture de référence dans une zone d’atterrissage Azure.
Détails du scénario
Le diagramme précédent montre un déploiement de base d’une seule machine virtuelle dans un réseau virtuel. Ce scénario est utile pour fournir une charge de travail non critique pour les utilisateurs internes uniquement.
Cas d’usage potentiels
Cette architecture convient à une application simple qui n’a pas besoin d’exposition à Internet public et peut tolérer des temps d’arrêt occasionnels. Un outil de création de rapports interne de base est un cas d’usage classique.
Considérations
Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.
Reliability
La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour plus d'informations, veuillez consulter la liste de vérification de la conception pour la fiabilité.
Cet exemple d’architecture utilise une seule machine virtuelle, ce qui permet de fournir un niveau minimal de fiabilité. Tout problème lié à la machine virtuelle ou à l’hôte où il s’exécute provoque une panne et rend les charges de travail hébergées indisponibles. Pour toute charge de travail nécessitant une disponibilité plus élevée, déployez plusieurs machines virtuelles qui contiennent la même charge de travail et placez ces instances derrière une solution d’équilibrage de charge appropriée. S'ils se trouvent dans la même région, déployez ces machines virtuelles dans des zones de disponibilité (où elles sont prises en charge) et ajoutez-les au serveur principal d'un Azure Standard Load Balancer ou à une passerelle Application Gateway si la charge de travail est basée sur HTTP/HTTPS. Cette architecture permet à la charge de travail de rester disponible si une seule machine virtuelle du serveur principal tombe en panne.
Les groupes de machines virtuelles identiques sont une autre option permettant de simplifier la gestion des charges de travail à plusieurs nœuds qui ont besoin de mettre automatiquement à l’échelle le nombre d’instances en fonction de l’une ou l’autre des métriques telles que la consommation du processeur et de la mémoire.
Haute disponibilité et reprise après sinistre (HA/DR)
Pour réduire le rayon d’explosion et améliorer la résilience, déployez la charge de travail dans plusieurs régions et utilisez les instructions de zone d’atterrissage Azure. Ce déploiement peut se trouver dans une configuration active-passive, avec un basculement vers la région secondaire si la région primaire devient indisponible ou une architecture active active où les deux régions servent le trafic vers les consommateurs.
Pour obtenir un exemple, consultez l’application web multitier conçue pour la haute disponibilité et la récupération d’urgence. L’exemple de cet article utilise Azure Site Recovery pour répliquer les disques de machines virtuelles individuelles vers une région secondaire. Vous pouvez utiliser Site Recovery pour effectuer le basculement de ces machines virtuelles vers la région secondaire avec un objectif de point de récupération (RPO) faible et un objectif de délai de récupération (RTO) faible.
Veillez à évaluer votre architecture pour répondre à vos besoins en haute disponibilité/récupération d’urgence sur tous les composants, et non seulement les machines virtuelles. Dans toutes ces décisions, incluez des considérations telles que la mise en réseau, l’identité et les données.
Sécurité
La sécurité offre des protections contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour plus d’informations, consultez liste de vérification pour la révision de conception concernant la sécurité.
Tenez compte de ces points lorsque vous développez votre architecture :
Utilisez Microsoft Defender for Cloud pour obtenir une vue centrale de l’état de sécurité de vos ressources Azure. Defender for Cloud surveille les problèmes de sécurité potentiels et fournit une image complète de l’intégrité de la sécurité de votre déploiement. Configurez Defender for Cloud par abonnement Azure et activez la collecte des données de sécurité. Defender for Cloud analyse automatiquement les machines virtuelles créées sous cet abonnement.
Gestion des correctifs : En cas d’activation, Defender for Cloud identifie les mises à jour critiques et de sécurité manquantes.
Anti-programme malveillant : Lorsqu’il est activé, Defender for Cloud vérifie si le logiciel anti-programme malveillant est installé. Vous pouvez également utiliser Defender for Cloud pour installer des logiciels anti-programmes malveillants directement à partir du portail Azure.
Utilisez Azure contrôle d’accès en fonction du rôle (Azure RBAC) pour contrôler l’accès aux ressources Azure. Avec Azure RBAC, vous accordez uniquement aux utilisateurs les autorisations dont ils ont besoin pour effectuer leur travail. Par exemple, le rôle Lecteur peut afficher Azure ressources, mais ne peut pas les créer, les gérer ou les supprimer. Certaines autorisations sont spécifiques à un type de ressource Azure. Par exemple, le rôle Contributeur de machine virtuelle peut redémarrer ou libérer une machine virtuelle, réinitialiser le mot de passe administrateur et créer une machine virtuelle. D’autres rôles définis qui peuvent être utiles pour cette architecture incluent DevTest Labs User et Network Contributor.
Note
Azure RBAC ne limite pas les actions qu'un utilisateur connecté à une machine virtuelle peut effectuer. Le type de compte sur le système d’exploitation invité détermine ces autorisations.
Utilisez les journaux d’audit pour voir les actions d’approvisionnement et d’autres événements concernant la machine virtuelle.
Activez le chiffrement sur l’hôte pour obtenir un chiffrement de bout en bout pour vos données de machine virtuelle, y compris les disques temporaires et les caches de disque. Le chiffrement au niveau de l'hôte gère le chiffrement sur l'infrastructure hôte de machine virtuelle et, contrairement au chiffrement basé sur l'invité, n'utilise pas les ressources du processeur de la machine virtuelle. Vous pouvez utiliser des clés gérées par customer avec Azure Key Vault pour les disques de données et de système d’exploitation persistants. Les disques temporaires et les disques de système d’exploitation éphémères sont chiffrés avec des clés gérées par la plateforme. Vérifiez que la taille de votre machine virtuelle VM sélectionnée prend en charge le chiffrement sur l’hôte avant de provisionner la machine virtuelle.
Optimisation des coûts
L’optimisation des coûts se concentre sur la recherche de moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez la liste de vérification de conception pour l’optimisation des coûts.
Il existe différentes options pour les tailles de machine virtuelle en fonction de l’utilisation et de la charge de travail. La gamme comprend l’option la plus économique de la série Bs vers les machines virtuelles GPU les plus récentes optimisées pour machine learning. Pour plus d’informations sur les options disponibles, consultez Azure tarification des machines virtuelles Linux.
Pour les charges de travail prévisibles, utilisez réservations Azure et plan d’économies Azure pour le calcul. Un contrat d’un an ou de trois ans peut réduire considérablement les coûts de calcul par rapport aux tarifs de paiement à l’utilisation. Pour les charges de travail sans temps de réalisation prévisible ou la consommation des ressources, envisagez l’option Paiement à l’utilisation.
Les machines virtuelles Spot Azure utilisent la capacité inutilisée d’Azure à des tarifs nettement réduits. Azure peut évincer les machines virtuelles Spot avec un préavis très court lorsqu’il a besoin de récupérer cette capacité. Elles ne conviennent donc qu’aux charges de travail tolérantes aux pannes sans date limite d’achèvement stricte. Envisagez les machines virtuelles Spot pour :
- Scénarios de calcul haute performance, travaux de traitement par lots ou applications de rendu visuel.
- Environnements de test, y compris les charges de travail d’intégration continue et de livraison continue.
- Applications sans état à grande échelle.
Utilisez la calculatrice de prix Azure pour estimer les coûts.
Excellence opérationnelle
L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et la conservent en production. Pour plus d’informations, consultez Liste de vérification de la conception pour l'excellence opérationnelle.
Utilisez des modèles d’infrastructure en tant que code (IaC) pour approvisionner des ressources Azure et leurs dépendances. Vous pouvez écrire ces modèles à l’aide de Bicep, de Azure Resource Manager ou de Terraform. Ces modèles peuvent être utilisés dans le cadre d’un pipeline d’intégration continue et de déploiement continu (CI/CD) via un déploiement automatisé. Cette approche fournit un contrôle de version sur votre architecture, garantit la cohérence entre les environnements et applique la reproductibilité, la sécurité et la conformité.
Pour faciliter la surveillance et le diagnostic des problèmes, activez les journaux de diagnostic sur vos ressources et envoyez-les à Azure Monitor pour l’analyse et l’optimisation. Vous pouvez utiliser ces journaux pour implémenter des alertes et des notifications d’événements critiques, et dans certains cas, autoriser la correction automatisée ou la journalisation des tickets dans votre système ITSM (IT Service Management).
Efficacité des performances
L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. Pour en savoir plus, consultez Liste de vérification de l'examen de la conception pour l'efficacité des performances
L’efficacité des performances vous permet de réduire la latence, d’obtenir des architectures évolutives, d’optimiser l’utilisation des ressources et d’améliorer en permanence les performances du système. Les décisions que vous prenez en matière d’architecture de charge de travail, de taille de machine virtuelle et de configurations de disque peuvent considérablement affecter les performances de votre charge de travail. Faire les bons choix peut empêcher la nécessité de réorganiser la solution à l’avenir, d’ajouter de la flexibilité et d’économiser des coûts.
Tenez compte de ces points lorsque vous développez votre architecture :
Utilisez Virtual Machine Scale Sets si la charge de travail a une charge dynamique. Par exemple, augmentez la capacité en période de fort trafic, puis réduisez-la lorsque le trafic baisse. Cette approche garantit une puissance de traitement adéquate tout en maintenant les coûts sous contrôle.
Choisissez les références SKU de machine virtuelle et de disque appropriées pour répondre aux E/S par seconde requises pendant le traitement. Configurez la mise en cache pour améliorer davantage les performances.
Si votre charge de travail est inhabituellement sensible à la latence, utilisez des groupes de placement de proximité (PPG) afin de garantir que plusieurs machines virtuelles soient physiquement proches les unes des autres pour obtenir de meilleures performances. Vous pouvez également combiner des PPG avec des groupes à haute disponibilité pour obtenir une faible latence et une haute disponibilité au sein d’un seul centre de données physique.
Dans la mesure du possible, activez la mise en réseau accélérée pour réduire la latence entre les composants.
Concevez l’architecture réseau pour réduire les tronçons inutiles.
Utilisez Azure Monitor et d’autres outils pour analyser en permanence les métriques et créer des bases de référence de performances mises à jour. Utilisez les informations de performances pour déterminer où implémenter des modifications, puis testez-les sur ces bases de référence.
Contributors
Microsoft conserve cet article. Les contributeurs suivants ont rédigé l’article.
Auteur principal :
- Donnie Trumpower | Senior Cloud &AI Solutions Architect
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
- Quickstart : Créer une machine virtuelle Linux dans le portail Azure
- Installer des pilotes GPU NVIDIA sur des machines virtuelles de série N exécutant Linux
- Tutoriel : Créer et gérer des machines virtuelles Linux avec le Azure CLI
- Accès sortant par défaut dans Azure