Migración de una red virtual (clásica) de un grupo de afinidad a una región

Importante

Azure tiene dos modelos de implementación diferentes para crear recursos y trabajar con ellos: Resource Manager y el clásico. Este artículo trata del modelo de implementación clásico. Microsoft recomienda que las implementaciones más recientes usen el modelo de implementación de Resource Manager.

Los grupos de afinidad garantizan que los recursos creados en el mismo grupo de afinidad se hospedan físicamente en servidores que están cerca, lo que permite que estos recursos se comuniquen con mayor rapidez. En el pasado, los grupos de afinidad eran un requisito para crear redes virtuales (clásicas). En ese momento, el servicio de administrador de red que administraba las redes virtuales (clásicas) solo podía trabajar en un conjunto de servidores físicos o una unidad de escalado. Mejoras arquitectónicas han aumentado el ámbito de administración de red a una región.

Como resultado de estas mejoras de arquitectura, los grupos de afinidad ya no se recomiendan ni son necesarios para las redes virtuales (clásicas). El uso de grupos de afinidad para redes virtuales (clásicas) se reemplaza por regiones. Las redes virtuales (clásicas) que están asociadas a regiones se denominan redes virtuales regionales.

Por lo general, se recomienda no usar grupos de afinidad. Además del requisito de redes virtuales, también era importante usar los grupos de afinidad para asegurarse de que los recursos, por ejemplo, de proceso (clásico) y almacenamiento (clásico), se colocaran próximos entre sí. Sin embargo, con la arquitectura de red de Azure actual, estos requisitos de colocación ya no son necesarios.

Importante

Aunque es técnicamente posible crear una red virtual que está asociada a un grupo de afinidad, no hay ninguna razón para hacerlo. Muchas características de red virtual, como los grupos de seguridad de red, solo están disponibles cuando se usa una red virtual regional y no están disponibles para las redes virtuales que están asociadas a grupos de afinidad.

Edición del archivo de configuración de red

  1. Exporte un archivo de configuración de red. Para más información sobre cómo exportar un archivo de configuración de red con PowerShell o la interfaz de línea de comandos (CLI) 1.0 de Azure, consulte Configuración de una red virtual mediante un archivo de configuración de red.

  2. Edite el archivo de configuración de red, y reemplace AffinityGroup por Location. Especifique una región de Azure para Location.

    Nota

    Location es la región que especificó para el grupo de afinidad que está asociado a la red virtual (clásica). Por ejemplo, si la red virtual (clásica) está asociada a un grupo de afinidad que se encuentra en Oeste de EE. UU., al migrar, el valor de Location debe apuntar a Oeste de EE. UU.

    Edite las líneas siguientes del archivo de configuración de red y reemplace los valores por los suyos propios:

    Valor anterior:< VirtualNetworkSitename="VNetUSWest" AffinityGroup="VNetDemoAG">

    Nuevo valor:< VirtualNetworkSitename="VNetUSWest" Location="West US">

  3. Guarde los cambios e importe la configuración de red en Azure.

Nota

Esta migración NO causa ningún tiempo de inactividad en sus servicios.

Qué hacer si tiene una máquina virtual (clásica= en un grupo de afinidad

No es necesario quitar las máquinas virtuales (clásicas) que están en un grupo de afinidad de dicho grupo. Una vez implementada una máquina virtual, se implementa en una sola unidad de escalado. Los grupos de afinidad pueden restringir el conjunto de tamaños de máquina virtual disponibles para una nueva implementación de máquina virtual, pero cualquier máquina virtual existente que esté implementa ya está restringida al conjunto de tamaños de máquina virtual disponible en la unidad de escalado en el que se implementa la máquina virtual. Dado que la máquina virtual se ha implementado en una unidad de escalado, quitar una máquina virtual de un grupo de afinidad no tiene ningún efecto en la máquina virtual.