Quelle est la différence entre Virtual Machine classic et virtual machine dans azure?
Dans Azure, 2 options sont disponibles pour créer des machines virtuelles. A. normal de la VM B. VM classique
Est-ce que quelqu'un sait quelle est la différence entre les deux options? Quand utilisons-nous l'un sur l'autre?
4 réponses
Réponse Courte à votre question est Normal VM or Virtual Machines est la nouvelle façon de déployer vos Machines Virtuelles alors que Classic VM or Virtual Machines (Classic) est l'ancienne manière de les déployer. Azure pousse vers la nouvelle façon de déployer des ressources de sorte que la recommandation serait de l'utiliser au lieu de l'ancienne façon. Cependant gardez à l'esprit qu'il existe certaines fonctionnalités disponibles à l'ancienne qui n'ont pas été portées sur la nouvelle manière il vous suffit donc de comparer les fonctionnalités offertes et seulement si quelque chose dont vous avez besoin ne l'est pas disponible de manière nouvelle, vous utilisez l'ancienne.
Maintenant vient la longue réponse:)
Essentiellement, il existe une API REST à l'aide de laquelle vous interagissez avec L'Infrastructure Azure.
Quand Azure a commencé, cette API a été appelée Service Management API (SMAPI) qui a très bien servi son but à cette époque (et dans une certaine mesure aujourd'hui). Cependant, comme Azure a grandi, les exigences des utilisateurs aussi et C'est là que SMAPI a été trouvé limitant. Un bon exemple est le contrôle d'accès. Dans SMAPI, il y avait un contrôle d'accès mais il était plus comme all-or-none sorte de contrôle d'accès. Il manquait la granularité demandée par les utilisateurs.
Au lieu de patcher SMAPI pour répondre aux exigences de l'utilisateur, L'équipe Azure a décidé de réécrire l'API entière qui était beaucoup plus simple, plus robuste et riche en fonctionnalités. Cette API s'appelle Azure Resource Manager API (ARM). ARM a de nombreuses fonctionnalités qui ne sont pas là dans SMAPI (mon favori personnel est Role-based access control - RBAC).
Si vous avez remarqué qu'il y a deux Azure portails aujourd'hui - https://manage.windowsazure.com (old) et https://portal.azure.com (de nouvelles). Ancien portail prend en charge SMAPI tandis que le nouveau portail prend en charge ARM. Afin de faire apparaitre les ressources créées via l'ancien portail dans le nouveau portail (afin que vous puissiez avoir une expérience unifiée), L'équipe Azure a fini par créer un fournisseur de ressources pour les anciennes choses et leurs noms se termineront toujours par (Classic), vous verrez Virtual Machines (Classic), Storage Accounts (Classic) etc. Afin que les ressources que vous créez dans le vieux portail peut être vu dans le nouveau portail (à condition que le nouveau portail supporte) mais toutes les ressources que vous créez dans le nouveau portail à l'aide de BRAS ne sont pas affichés dans l'ancien portail.
La machine virtuelle Azure (classic) est basée sur L'ancien modèle de gestion de Service Azure (ASM). Qui tournait autour du concept d'un service cloud. Tout était contenu dans un service cloud, et c'était la passerelle vers internet. Alors qu'il est encore utilisé (largement), Azure passe maintenant au modèle de gestion des ressources Azure (ARM).
ARM utilise le concept de modèles déclaratifs pour configurer une solution entière (plutôt que des composants individuels) afin que vous puissiez créer une pile Sharepoint entière, plutôt qu'une machine singulière.
ARM a également une approche beaucoup plus logique de la mise en réseau. Au lieu d'avoir une machine virtuelle monolithique dans un service cloud obscur. Vous avez une machine virtuelle à laquelle vous attachez une carte réseau. Vous pouvez ensuite mettre la carte réseau dans un VNet et joindre une adresse IP publique (si vous en avez besoin)
Sauf si vous avez une raison impérieuse d'utiliser ASM (classic), vous devez créer votre solution en utilisant ARM. Comme c'est la recommandation MS à l'avenir (todo cela signifie également que vous pouvez créer des modèles pour vos déploiements, de sorte que vous pouvez avoir une solution reproductible.
Sur le négatif, l'ancien portail manage.windowsazure.com impossible de gérer tout ce qui est déployé en utilisant ARM, et il y a encore des parties D'ASM qui n'ont pas encore été migrées vers ARM. Par exemple, vous ne pouvez pas configurer Azure VM backup, car Azure backup est ASM et ne peut pas "voir" les VMs ARM
Cela dépend très largement de votre situation, quoi c'est pour cela que vous prévoyez, la méthode avec laquelle vous allez déployer. Si vous cherchez juste à tenir une machine pour faire une seule tâche, Cela fait très peu de différence. Si vous cherchez à déployer dans un environnement qui aura des concepts de DevOps à l'avenir, alors ARM est la voie à suivre.
Les grandes différences concernent la gestion des ressources. Pour cette nouvelle version est appelée Azure Resource Manager VM (ARM VM).
ARM VM est mieux en termes de;
- la VM classique doit être liée à Cloud Service , et le Service Cloud consomme une limitation des ressources et une configuration réseau moins flexible.
- la VM ARM est gérée sous Azure Resource Manager (ARM) qui peut être organisée avec / sans autres services Azure. ARM est comme un dossier de services Azure, et il vous donne une gestion des ressources plus fine.
La VM classique peut être migrée vers la version ARM VM, mais vous devez vous permettre des temps d'arrêt de service. Pour migrer à partir d'une machine virtuelle classique, lisez l'article officiel : Considérations pour les Machines virtuelles.
Azure fournit maintenant deux modèles de déploiement: Azure Resource Manager (Normal) et Azure Service Management(Classic) et certaines considérations importantes vous devriez vous soucier lorsque vous travaillez sur des Machines virtuelles.
- les machines virtuelles déployées avec le modèle de déploiement classique ne peuvent pas être incluses dans un réseau virtuel déployé avec Resource Manager.
- les machines virtuelles déployées avec le modèle de déploiement Resource Manager doivent être incluses dans un réseau virtuel.
- machines virtuelles déployé avec le modèle de déploiement classique n'a pas besoin d'être inclus dans un réseau virtuel.