Compartir vía

Migración del clúster de Service Fabric a la compatibilidad con la zona de disponibilidad

  • Artículo

En esta guía se describe cómo migrar clústeres de Service Fabric de compatibilidad con zonas de no disponibilidad a compatibilidad con zona de disponibilidad. Le guiaremos por las distintas opciones para la migración. Un clúster de Service Fabric distribuido en zonas de disponibilidad garantiza el estado de alta disponibilidad del clúster.

Puede migrar clústeres administrados y no administrados. Ambas opciones se describen en este artículo.

En el caso de los clústeres no administrados, se describen dos escenarios diferentes:

  • Migración de un clúster con un equilibrador de carga de SKU estándar y un recurso de IP. Esta configuración admite zonas de disponibilidad sin necesidad de crear nuevos recursos.
  • Migración de un clúster con un equilibrador de carga de SKU básico y un recurso de IP. Esta configuración no admite zonas de disponibilidad y requiere la creación de nuevos recursos.

Consulte las secciones adecuadas en cada encabezado del escenario de clúster de Service Fabric.

Nota:

La ventaja de abarcar el tipo de nodo principal entre zonas de disponibilidad solo se ve para tres zonas y no solo dos. Esto es cierto para los clústeres administrados y no administrados.

Hay plantillas de ejemplo disponibles en el repositorio de plantillas para uso entre zonas de disponibilidad de Service Fabric.

Requisitos previos

Clústeres administrados de Service Fabric

Requerido:

Se recomienda que use:

  • El SKU del clúster debe ser Estándar.
  • El tipo de nodo principal debe tener al menos nueve nodos para obtener la mejor resistencia, aunque se admite un número mínimo de seis.
  • Los tipos de nodos principales deben tener al menos seis nodos para obtener la mejor resistencia, aunque se admite un número mínimo de tres.

Clústeres no administrados de Service Fabric

Obligatorio: N/D.

Se recomienda que use:

  • El nivel de confiabilidad del clúster ha de establecerse en Platinum.
  • Un único recurso de IP pública que use la SKU Estándar.
  • Un único recurso de Load Balancer que use la SKU Estándar.
  • Un grupo de seguridad de red (NSG) referenciado por la subred en la que implementar los conjuntos de escalado de máquinas virtuales.

Equilibrador de carga y recurso IP de SKU estándar existentes

No hay ningún requisito previo para este escenario, ya que supone que tiene los recursos necesarios existentes.

Equilibrador de carga de SKU básico y recurso de IP

  • Un nuevo equilibrador de carga con la SKU estándar, distinto del equilibrador de carga de la SKU básica existente.
  • Un nuevo recurso de IP con la SKU estándar, distinto del recurso de IP de SKU básica existente.

Nota:

No es posible actualizar los recursos existentes de una SKU básica a una SKU estándar, por lo que se requieren nuevos recursos.

Requisitos de tiempo de inactividad

Clúster administrado de Service Fabric

La migración a una configuración con resistencia de zona puede causar una pérdida breve de conectividad externa a través del equilibrador de carga, pero no afecta al estado del clúster. La pérdida de conectividad externa se produce cuando se debe crear una nueva dirección IP pública para que las redes sean resistentes a los errores de zona. Planee la migración en consecuencia.

Clúster no administrado de Service Fabric

El tiempo de inactividad para migrar clústeres no administrados de Service Fabric varía ampliamente en función del número de máquinas virtuales y dominios de actualización (UD) del clúster. Los identificadores de usuario son agrupaciones lógicas de máquinas virtuales que determinan el orden en que se insertan las actualizaciones en las máquinas virtuales del clúster. El tiempo de inactividad también se ve afectado por el modo de actualización del clúster, que controla cómo se procesan las tareas de actualización de los identificadores del clúster. La propiedad sfZonalUpgradeMode, que controla el modo de actualización, se trata con más detalle en las secciones siguientes.

Migración de clústeres administrados de Service Fabric

Siga los pasos descritos en Migración de un clúster administrado de Service Fabric a una zona resistente.

Opciones de migración para clústeres no administrados de Service Fabric

Opción de migración 1: habilitar varias zonas de disponibilidad en un único conjunto de escalado de máquinas virtuales

Cuándo usar esta opción

Esta solución permite a los usuarios abarcar tres instancias de Availability Zones en el mismo tipo de nodo. Se trata de la topología de implementación recomendada, ya que permite realizar la implementación entre zonas de disponibilidad mientras se mantiene un único conjunto de escalado de máquinas virtuales.

GitHub tiene una plantilla de ejemplo a su disposición.

Debe usar esta opción cuando tenga un clúster no administrado de Service Fabric existente con el equilibrador de carga de SKU estándar y los recursos de IP que desea migrar. Si el clúster no administrado existente tiene recursos de SKU básica, debería ver la opción migración de SKU básica a continuación.

Migración del clúster no administrado de Service Fabric con recursos de IP y equilibrador de carga de SKU estándar existentes

Para habilitar zonas en un conjunto de escalado de máquinas virtuales:

Incluya los tres valores siguientes en el recurso Conjunto de escalado de máquinas virtuales:

  • El primer valor es la propiedad zones, que especifica las zonas de disponibilidad que están presentes en el conjunto de escalado de máquinas virtuales.

  • El segundo valor es la propiedad singlePlacementGroup, que se debe establecer en true. El conjunto de escalado que se extiende entre tres zona de disponibilidad puede admitir hasta 300 máquinas virtuales incluso con singlePlacementGroup = true.

  • El tercer valor es zoneBalance, que garantiza el equilibrio de zona estricta. Este valor debe ser true. Esto garantiza que las distribuciones de máquinas virtuales entre zonas no sean desiguales, lo cual significa que cuando una de las zonas deja de funcionar, las otras dos zonas disponen de suficientes máquinas virtuales para que el clúster sigue ejecutándose.

    Es posible que un clúster con una distribución desigual de máquinas virtuales no sobreviva a un escenario de zona fuera de servicio, ya que esa zona podría acaparar la mayoría de las máquinas virtuales. La distribución desigual de máquinas virtuales entre zonas también provoca problemas relacionados con la prestación de servicios y el bloqueo de las actualizaciones de infraestructura. Más información sobre zoneBalancing.

No es necesario configurar las invalidaciones FaultDomain y UpgradeDomain.

{
  "apiVersion": "2018-10-01",
  "type": "Microsoft.Compute/virtualMachineScaleSets",
  "name": "[parameters('vmNodeType1Name')]",
  "location": "[parameters('computeLocation')]",
  "zones": [ "1", "2", "3" ],
  "properties": {
    "singlePlacementGroup": true,
    "zoneBalance": true
  }
}

Nota:

  • Los clústeres de Service Fabric deben tener al menos un tipo principal de nodo. El nivel de durabilidad de los tipos de nodo principal debe ser Silver o superior.
  • Una Azure Availability Zones de disponibilidad que extiende los conjuntos de escalado de máquinas virtuales debe configurarse con tres zona de disponibilidad como mínimo, independientemente del nivel de durabilidad.
  • Una zona de disponibilidad que extienden conjuntos de escalado de máquinas virtuales con el nivel de durabilidad Silver o superior deben tener al menos 15 máquinas virtuales.
  • La zona de disponibilidad que abarca el conjunto de escalado de máquinas virtuales con durabilidad Bronze debe tener al menos 6 máquinas virtuales.
Habilitación de la compatibilidad con varias zonas en el tipo de nodo de Service Fabric

El tipo de nodo de Service Fabric debe estar habilitado para admitir varias zonas de disponibilidad.

  • El primer valor es multipleAvailabilityZones, que se debe establecer en true para el tipo de nodo.

  • El segundo valor es sfZonalUpgradeMode y es opcional. Esta propiedad no se puede modificar si ya existe un tipo de nodo con varias zonas de disponibilidad en el clúster. Esta propiedad determina la agrupación lógica de máquinas virtuales en los dominios de actualización (UD).

    • Si este valor se establece en Parallel, las máquinas virtuales del tipo de nodo se agrupan en UD y omiten la información de zona en cinco UD. Esta configuración hace que los UD de todas las zonas se actualicen al mismo tiempo. Aunque este modo de implementación es más rápido para las actualizaciones. No se recomienda su uso, ya que se trata de instrucciones SDP que indican que las actualizaciones deben aplicarse en una zona cada vez.

    • Si el valor se omite o se establece en Hierarchical, las máquinas virtuales se agruparán para reflejar la distribución de zonas en un máximo de 15 UD. Cada una de las tres zonas tiene cinco UD. De este modo, se garantiza que las zonas se actualicen de una en una y que solo se pase a la zona siguiente después de completar cinco UD en la primera zona. Este proceso de actualización es más seguro para el clúster y la aplicación de usuario.

    La propiedad solo define el comportamiento de actualización de la aplicación Service Fabric y las actualizaciones de código. Las actualizaciones del conjunto subyacente de escalado de máquinas virtuales seguirán produciéndose simultáneamente en todas las zonas de disponibilidad. Esta propiedad no afecta a la distribución de UD para los tipos de nodo que no tengan habilitadas varias zonas.

  • El tercer valor es vmssZonalUpgradeMode, es opcional y se puede actualizar en cualquier momento. Esta propiedad define el esquema de actualización para que el conjunto de escalado de máquinas virtuales se pueda realizar en paralelo o secuencialmente en Availability Zones.

    • Si este valor se establece en Parallel: todas las actualizaciones del conjunto de escalado se suceden en paralelo en todas las zonas. Este modo de implementación es más rápido para las actualizaciones. No se recomienda su uso, ya que se trata de instrucciones SDP que indican que las actualizaciones deben aplicarse en una zona cada vez.
    • Si este valor se omite o se establece en Hierarchical: se garantiza que las zonas se actualicen de una en una y que solo se pase a la zona siguiente después de completar cinco UD en la primera zona. Este proceso de actualización es más seguro para el clúster y la aplicación de usuario.

Importante

La versión de API del recurso de clúster de Service Fabric debe ser la 2020-12-01 (versión preliminar) o superior.

La versión del código del clúster debe ser 8.1.321 o posterior.

{
  "apiVersion": "2020-12-01-preview",
  "type": "Microsoft.ServiceFabric/clusters",
  "name": "[parameters('clusterName')]",
  "location": "[parameters('clusterLocation')]",
  "dependsOn": [
    "[concat('Microsoft.Storage/storageAccounts/', parameters('supportLogStorageAccountName'))]"
  ],
  "properties": {
    "reliabilityLevel": "Platinum",
    "sfZonalUpgradeMode": "Hierarchical",
    "vmssZonalUpgradeMode": "Parallel",
    "nodeTypes": [
      {
        "name": "[parameters('vmNodeType0Name')]",
        "multipleAvailabilityZones": true
      }
    ]
  }
}

Nota:

  • Los recursos de IP pública y equilibrar la carga deben usar la SKU Estándar, tal como se describió anteriormente en el artículo.
  • La propiedad multipleAvailabilityZones del tipo de nodo solo se puede definir cuando se haya creado el tipo de nodo y no se podrá modificar más adelante. Los tipos de nodo existentes no se pueden configurar con esta propiedad.
  • Cuando sfZonalUpgradeMode se omite o se establece en Hierarchical, las implementaciones de clúster y aplicación serán más lentas porque habrá más dominios de actualización en el clúster. Es importante ajustar correctamente los tiempos de inactividad de la directiva de actualización para tener en cuenta el tiempo de actualización necesario para 15 dominios de actualización. La directiva de actualización para la aplicación y el clúster debe actualizarse para garantizar que la implementación no supere el límite de tiempo de implementación de 12 horas de Azure Resource Service. Esto significa que la implementación no debe tardar más de 12 horas para 15 UD (es decir, no debe tardar más de 40 minutos con cada UD).
  • Establezca el nivel de confiabilidad del clúster en Platinum para garantizar que el clúster sobreviva al escenario con una zona fuera de servicio.
  • No se admite la actualización de DurabilityLevel para un tipo de nodo con multipleAvailabilityZones. En su lugar, cree un tipo de nodo con mayor durabilidad.
  • SF solo admite tres AvailabilityZones. Por el momento, no se admite ningún número mayor.

Sugerencia

Se recomienda establecer sfZonalUpgradeMode en Hierarchical, o bien omitirlo. La implementación seguirá la distribución de zonas de las máquinas virtuales y afecta a un número más reducido de réplicas o instancias, por lo estas son más seguras. Use sfZonalUpgradeMode establecido en Parallel si la velocidad de implementación es una prioridad o solo se ejecuta una carga de trabajo sin estado en el tipo de nodo con varias zonas de disponibilidad. Esto hará que el recorrido del dominio de actualización tenga lugar al mismo tiempo en todas las zonas de disponibilidad.

Migración al tipo de nodo con varias zonas de disponibilidad

En todos los escenarios de migración, es necesario agregar un nuevo tipo de nodo que admita varias zonas de disponibilidad. No se puede migrar un tipo de nodo existente para admitir varias zonas. El artículo Escalado vertical de un del tipo de nodo principal de un clúster de Service Fabric incluye pasos detallados para agregar un nuevo tipo de nodo y los demás recursos necesarios para el nuevo tipo de nodo, como los recursos de IP y equilibrador de carga. En el artículo se describe también cómo retirar el tipo de nodo existente después de agregar al clúster un nuevo tipo de nodo con varias zonas de disponibilidad.

  • Migración desde un tipo de nodo que usa recursos de equilibrador de carga e IP básicos. Este proceso ya se describe en una subsección posterior para la solución con un tipo de nodo por zona de disponibilidad.

    Para el nuevo tipo de nodo, la única diferencia es que solo hay un conjunto de escalado de máquinas virtuales y un tipo de nodo para todas las zonas de disponibilidad, en lugar de uno por zona de disponibilidad.

  • Migración desde un tipo de nodo que usa los recursos de equilibrador de carga e IP de SKU Estándar con un NSG. Siga el procedimiento descrito anteriormente. Sin embargo, no es necesario agregar nuevos recursos de equilibrador de carga, IP y NSG. Se pueden reutilizar los mismos recursos en el nuevo tipo de nodo.

Si tiene algún problema, póngase en contacto con el soporte técnico para obtener ayuda.

Opción de migración 2: implementación de zonas mediante la asignación de un conjunto de escalado de máquinas virtuales a cada zona

Cuándo usar esta opción

Esta es la configuración disponible con carácter general en este momento.

Para extender un clúster de Service Fabric entre Availability Zones, debe crear un tipo de nodo principal en cada zona de disponibilidad admitida por la región. De este modo, se distribuyen nodos raíz de manera uniforme entre todos los tipos de nodos principales.

La topología recomendada para el tipo de nodo principal requiere lo siguiente:

  • Tres tipos de nodo deben marcarse como principales.
    • Cada tipo de nodo debe asignarse a su propio conjunto de escalado de máquinas virtuales ubicado en distintas zonas.
    • Cada conjunto de escalado de máquinas virtuales debe tener al menos cinco nodos (durabilidad Silver).

Debe usar esta opción cuando tenga un clúster no administrado de Service Fabric existente con el equilibrador de carga de SKU estándar y los recursos de IP que desea migrar. Si el clúster no administrado existente tiene recursos de SKU básica, debería ver la opción migración de SKU básica a continuación.

Migración del clúster no administrado de Service Fabric con recursos de IP y equilibrador de carga de SKU estándar existentes

Habilitación de zonas en un conjunto de escalado de máquinas virtuales

Para habilitar una zona en un conjuntos de escalado de máquinas virtuales, incluya estos tres valores en el recurso del conjunto de escalado de máquinas virtuales:

  • El primer valor es la propiedad zones, que especifica en qué zona de disponibilidad se implementará el conjunto de escalado de máquinas virtuales.
  • El segundo valor es la propiedad singlePlacementGroup, que se debe establecer en true.
  • El tercer valor es la propiedad faultDomainOverride en la extensión de conjunto de escalado de máquinas virtuales de Service Fabric. Esta propiedad debe incluir solo la zona en la que se incluirá este conjunto de escalado de máquinas virtuales. Ejemplo: "faultDomainOverride": "az1". Todos los recursos del conjunto de escalado de máquinas virtuales se deben incluir en la misma región porque los clústeres de Azure Service Fabric no ofrecen compatibilidad entre regiones.
{
  "apiVersion": "2018-10-01",
  "type": "Microsoft.Compute/virtualMachineScaleSets",
  "name": "[parameters('vmNodeType1Name')]",
  "location": "[parameters('computeLocation')]",
  "zones": [
    "1"
  ],
  "properties": {
    "singlePlacementGroup": true
  },
  "virtualMachineProfile": {
    "extensionProfile": {
      "extensions": [
        {
          "name": "[concat(parameters('vmNodeType1Name'),'_ServiceFabricNode')]",
          "properties": {
            "type": "ServiceFabricNode",
            "autoUpgradeMinorVersion": false,
            "publisher": "Microsoft.Azure.ServiceFabric",
            "settings": {
              "clusterEndpoint": "[reference(parameters('clusterName')).clusterEndpoint]",
              "nodeTypeRef": "[parameters('vmNodeType1Name')]",
              "dataPath": "D:\\\\SvcFab",
              "durabilityLevel": "Silver",
              "certificate": {
                "thumbprint": "[parameters('certificateThumbprint')]",
                "x509StoreName": "[parameters('certificateStoreValue')]"
              },
              "systemLogUploadSettings": {
                "Enabled": true
              },
              "faultDomainOverride": "az1"
            },
            "typeHandlerVersion": "1.0"
          }
        }
      ]
    }
  }
}
Habilitación de varios tipos de nodos principales en el recurso de clúster de Service Fabric

Para establecer uno o más tipos de nodo como principales en un recurso de clúster, establezca la propiedad isPrimary en true. Al implementar un clúster de Service Fabric en Availability Zones, debe tener tres tipos de nodo en distintas zonas.

{
  "reliabilityLevel": "Platinum",
  "nodeTypes": [
    {
      "name": "[parameters('vmNodeType0Name')]",
      "applicationPorts": {
        "endPort": "[parameters('nt0applicationEndPort')]",
        "startPort": "[parameters('nt0applicationStartPort')]"
      },
      "clientConnectionEndpointPort": "[parameters('nt0fabricTcpGatewayPort')]",
      "durabilityLevel": "Silver",
      "ephemeralPorts": {
        "endPort": "[parameters('nt0ephemeralEndPort')]",
        "startPort": "[parameters('nt0ephemeralStartPort')]"
      },
      "httpGatewayEndpointPort": "[parameters('nt0fabricHttpGatewayPort')]",
      "isPrimary": true,
      "vmInstanceCount": "[parameters('nt0InstanceCount')]"
    },
    {
      "name": "[parameters('vmNodeType1Name')]",
      "applicationPorts": {
        "endPort": "[parameters('nt1applicationEndPort')]",
        "startPort": "[parameters('nt1applicationStartPort')]"
      },
      "clientConnectionEndpointPort": "[parameters('nt1fabricTcpGatewayPort')]",
      "durabilityLevel": "Silver",
      "ephemeralPorts": {
        "endPort": "[parameters('nt1ephemeralEndPort')]",
        "startPort": "[parameters('nt1ephemeralStartPort')]"
      },
      "httpGatewayEndpointPort": "[parameters('nt1fabricHttpGatewayPort')]",
      "isPrimary": true,
      "vmInstanceCount": "[parameters('nt1InstanceCount')]"
    },
    {
      "name": "[parameters('vmNodeType2Name')]",
      "applicationPorts": {
        "endPort": "[parameters('nt2applicationEndPort')]",
        "startPort": "[parameters('nt2applicationStartPort')]"
      },
      "clientConnectionEndpointPort": "[parameters('nt2fabricTcpGatewayPort')]",
      "durabilityLevel": "Silver",
      "ephemeralPorts": {
        "endPort": "[parameters('nt2ephemeralEndPort')]",
        "startPort": "[parameters('nt2ephemeralStartPort')]"
      },
      "httpGatewayEndpointPort": "[parameters('nt2fabricHttpGatewayPort')]",
      "isPrimary": true,
      "vmInstanceCount": "[parameters('nt2InstanceCount')]"
    }
  ]
}

Si tiene algún problema, póngase en contacto con el soporte técnico para obtener ayuda.

Opción de migración: clúster no administrado de Service Fabric con el equilibrador de carga de SKU básico y los recursos de IP

Cuándo usar esta opción

Debe usar esta opción cuando tenga un clúster no administrado de Service Fabric existente con el equilibrador de carga de SKU básico y los recursos de IP que desea migrar. Si el clúster no administrado existente tiene recursos de SKU estándar, debería ver las opciones de migración anteriores. Si aún no ha creado el clúster no administrado, pero sabe que quiere que esté habilitado para AZ, créelo con recursos de SKU estándar.

Migración del clúster no administrado de Service Fabric con un equilibrador de carga de SKU básico y recursos de IP

Para migrar un clúster que usa una instancia de equilibrador de carga y una IP con una SKU Básica, primero deberá crear un recurso completamente nuevo de equilibrador de carga e IP mediante la SKU Estándar. No es posible actualizar estos recursos.

Haga referencia al nuevo equilibrador de carga e IP en los nuevos tipos de nodo entre zonas de disponibilidad que desea usar. En el ejemplo anterior, se agregaron tres nuevos recursos de conjunto de escalado de máquinas virtuales en las zonas 1, 2 y 3. Estos conjuntos de escalado de máquinas virtuales hacen referencia a al equilibrador de carga e IP recién creados y se identifican como tipos de nodo principal en el recurso de clúster de Service Fabric.

  1. Para empezar, agregue los nuevos recursos a la plantilla existente de Azure Resource Manager. Estos recursos incluyen:

    • Un recurso de IP pública que usa la SKU Estándar.
    • Un recurso de equilibrador de carga que usa la SKU Estándar.
    • Un NSG referenciado por la subred en la que se implementan los conjuntos de escalado de máquinas virtuales
    • Tres tipos de nodo deben marcarse como principales.
      • Cada tipo de nodo debe asignarse a su propio conjunto de escalado de máquinas virtuales ubicado en distintas zonas.
      • Cada conjunto de escalado de máquinas virtuales debe tener al menos cinco nodos (durabilidad Silver).

    Puede encontrar un ejemplo de estos recursos en la plantilla de ejemplo.

    New-AzureRmResourceGroupDeployment `
    -ResourceGroupName $ResourceGroupName `
    -TemplateFile $Template `
    -TemplateParameterFile $Parameters

  2. Una vez que ha terminado la implementación de los recursos, puede deshabilitar los nodos en el tipo de nodo principal del clúster original. Cuando los nodos estén deshabilitados, los servicios del sistema se migrarán al nuevo tipo de nodo principal que implementó anteriormente.

    Connect-ServiceFabricCluster -ConnectionEndpoint $ClusterName `
    -KeepAliveIntervalInSec 10 `
    -X509Credential `
    -ServerCertThumbprint $thumb  `
    -FindType FindByThumbprint `
    -FindValue $thumb `
    -StoreLocation CurrentUser `
    -StoreName My 

Write-Host "Connected to cluster"

$nodeNames = @("_nt0_0", "_nt0_1", "_nt0_2", "_nt0_3", "_nt0_4")

Write-Host "Disabling nodes..."
foreach($name in $nodeNames) {
    Disable-ServiceFabricNode -NodeName $name -Intent RemoveNode -Force
}

  3. Una vez que todos los nodos están deshabilitados, los servicios del sistema se ejecutarán en el tipo de nodo principal, que se extiende entre zonas. A continuación, puede quitar los nodos deshabilitados del clúster. Después de quitar los nodos, puede quitar los recursos de IP original, de equilibrador de carga y de conjunto de escalado de máquinas virtuales.

    foreach($name in $nodeNames){
    # Remove the node from the cluster
    Remove-ServiceFabricNodeState -NodeName $name -TimeoutSec 300 -Force
    Write-Host "Removed node state for node $name"
}

$scaleSetName="nt0"
Remove-AzureRmVmss -ResourceGroupName $groupname -VMScaleSetName $scaleSetName -Force

$lbname="LB-cluster-nt0"
$oldPublicIpName="LBIP-cluster-0"
$newPublicIpName="LBIP-cluster-1"

Remove-AzureRmLoadBalancer -Name $lbname -ResourceGroupName $groupname -Force
Remove-AzureRmPublicIpAddress -Name $oldPublicIpName -ResourceGroupName $groupname -Force

  4. A continuación, quite las referencias a estos recursos de la plantilla de Resource Manager que se implementó.

  5. Para finalizar, actualice el nombre DNS y la dirección IP pública.

$oldprimaryPublicIP = Get-AzureRmPublicIpAddress -Name $oldPublicIpName  -ResourceGroupName $groupname
$primaryDNSName = $oldprimaryPublicIP.DnsSettings.DomainNameLabel
$primaryDNSFqdn = $oldprimaryPublicIP.DnsSettings.Fqdn

Remove-AzureRmLoadBalancer -Name $lbname -ResourceGroupName $groupname -Force
Remove-AzureRmPublicIpAddress -Name $oldPublicIpName -ResourceGroupName $groupname -Force

$PublicIP = Get-AzureRmPublicIpAddress -Name $newPublicIpName  -ResourceGroupName $groupname
$PublicIP.DnsSettings.DomainNameLabel = $primaryDNSName
$PublicIP.DnsSettings.Fqdn = $primaryDNSFqdn
Set-AzureRmPublicIpAddress -PublicIpAddress $PublicIP

Si tiene algún problema, póngase en contacto con el soporte técnico para obtener ayuda.

Pasos siguientes