través - portal azure web

¿Cuál es la diferencia entre máquina virtual clásica y máquina virtual en azul?

Question

En Azure, hay 2 opciones disponibles para crear máquinas virtuales. A. VM normal B. VM clásica

¿Alguien sabe cuál es la diferencia entre ambas opciones? ¿Cuándo usamos uno sobre otro?

Answer 1

Azure proporciona ahora dos modelos de implementación: Azure Resource Manager (Normal) y Azure Service Management (Classic) y algunas consideraciones importantes que debe tener en cuenta al trabajar con Virtual Machines.

1. Las máquinas virtuales implementadas con el modelo de implementación clásico no se pueden incluir en una red virtual implementada con Resource Manager.
2. Las máquinas virtuales implementadas con el modelo de implementación de Resource Manager se deben incluir en una red virtual.
3. Las máquinas virtuales implementadas con el modelo de implementación clásico no tienen que incluirse en una red virtual.

Answer 2

La única gran diferencia es para la administración de recursos. Para esa nueva versión se llama Azure Resource Manager VM (ARM VM).

ARM VM es mejor en términos de;

• La máquina virtual clásica debe vincularse con el servicio en la nube , y el servicio en la nube consume la limitación de recursos y la configuración de red no tan flexible.
• ARM VM se administra bajo Azure Resource Manager (ARM), que se puede organizar con / sin otros servicios de Azure. ARM es como una carpeta de servicios de Azure, y le brinda una administración de recursos más detallada.

La VM clásica se puede migrar a la versión ARM VM, pero debe permitirse el tiempo de inactividad del servicio. Para migrar desde la máquina virtual clásica, lea el artículo oficial: Consideraciones para máquinas virtuales .

Answer 3

La máquina virtual de Azure (clásica) se basa en el antiguo modelo de gestión de servicios de Azure (ASM). Lo cual giró en torno al concepto de un servicio en la nube. Todo estaba contenido dentro de un servicio en la nube, y esa era la puerta de entrada a Internet. Mientras todavía se usa (ampliamente), Azure ahora se está trasladando al Modelo de administración de recursos de Azure (ARM).

ARM usa el concepto de plantillas declarativas para configurar una solución completa (en lugar de componentes individuales) para que pueda crear una pila de Sharepoint completa, en lugar de solo una máquina singular.

ARM también tiene un enfoque mucho más lógico para la creación de redes. En lugar de tener una máquina virtual monolítica en un oscuro servicio en la nube. Usted tiene una VM, a la que le adjunta una tarjeta de red. Luego puede colocar la tarjeta de red en una red virtual y adjuntar una IP pública (si necesita una)

A menos que tenga una razón convincente para usar ASM (clásico) Debe crear su solución usando ARM. Como esta es la recomendación de MS en el futuro (todo encuentre un enlace a eso) También significa que puede crear plantillas para sus implementaciones, para que pueda tener una solución repetible.

En lo negativo, el viejo portal manage.windowsazure.com no puede administrar nada que se implemente utilizando ARM, y todavía hay partes de ASM que aún no se han migrado a ARM. Por ejemplo, no puede configurar la copia de seguridad de Azure VM, ya que la copia de seguridad de Azure es ASM y no puede "ver" las máquinas virtuales de ARM.

Sin embargo, depende en gran medida de tus circunstancias, de lo que estás planeando, del método con el que vas a implementar. Si solo estás mirando parando una máquina para hacer una sola tarea, hay muy poca diferencia. Si está buscando implementar en un entorno que tendrá algunos conceptos de DevOps en el futuro, entonces ARM es el camino a seguir.

Answer 4

La respuesta breve a su pregunta es Normal VM or Virtual Machines es la nueva forma de implementar sus máquinas virtuales, mientras que Classic VM or Virtual Machines (Classic) es la forma antigua de implementarlas. Azure está presionando hacia la nueva forma de implementar los recursos, por lo que la recomendación sería usarla en lugar de hacerlo a la antigua. Sin embargo, tenga en cuenta que hay algunas funciones disponibles a la antigua que no se han transferido a la nueva forma, por lo que solo tiene que comparar las funciones ofrecidas y solo si algo que necesita no está disponible de una manera nueva. , usas el viejo modo.

Ahora viene la respuesta larga :)

Básicamente, hay una API REST con la que interactúa con Azure Infrastructure.

Cuando Azure comenzó, esta API se llamaba Service Management API (SMAPI) que cumplió su propósito bastante bien en ese momento (y hasta cierto punto hoy). Sin embargo, a medida que Azure creció, también lo hicieron los requisitos de los usuarios y ahí es donde se encontró que SMAPI era limitante. Un buen ejemplo es el control de acceso. En SMAPI, había control de acceso, pero era más como all-or-none tipo de control de acceso all-or-none . Carecía de la granularidad que pedían los usuarios.

En lugar de parchear SMAPI para cumplir con los requisitos del usuario, el equipo de Azure decidió reescribir toda la API, que era mucho más simple, más robusta y rica en funciones. Esta API se llama Azure Resource Manager API (ARM) . ARM tiene muchas características que no están en SMAPI (mi favorito es el Role-based access control - RBAC ).

Si ha notado que hay dos portales de Azure hoy, https://manage.windowsazure.com (antiguo) y https://portal.azure.com (nuevo). El portal antiguo es compatible con SMAPI, mientras que el nuevo portal admite ARM. Con el fin de aumentar los recursos creados a través de un portal antiguo en un nuevo portal (para que pueda tener una experiencia unificada), el equipo de Azure terminó creando un proveedor de recursos para cosas viejas y sus nombres siempre terminarán con (Classic) para que vea Virtual Machines (Classic) , Storage Accounts (Classic) etc. Por lo tanto, los recursos que cree en el portal anterior se pueden ver en el nuevo portal (siempre que el nuevo portal los admita), pero los recursos que cree en el nuevo portal utilizando ARM no se muestran en el viejo portal.