Compartir a través de


Escalado vertical del tipo de nodo no principal de un clúster de Service Fabric

En este artículo se explica cómo se escala verticalmente el tipo de nodo no principal de un clúster de Service Fabric con el tiempo de inactividad mínimo. Las actualizaciones de SKU locales no se admiten en nodos de clúster de Service Fabric, ya que estas operaciones pueden conllevar la pérdida de datos y de disponibilidad. El método más seguro, confiable y recomendado para escalar verticalmente un tipo de nodo de Service Fabric es:

  1. Agregue un nuevo tipo de nodo a su clúster de Service Fabric, respaldado por la configuración y la SKU del conjunto de escalado de máquinas virtuales actualizadas (o modificadas). Este paso también implica la configuración de un nuevo equilibrador de carga, una subred y una dirección IP pública para el conjunto de escalado.

  2. Una vez que los conjuntos de escalado originales y actualizados se ejecutan en paralelo, migre la carga de trabajo estableciendo restricciones de selección de ubicación para las aplicaciones al nuevo tipo de nodo.

  3. Compruebe que el clúster tenga un estado correcto y, a continuación, quite el conjunto de escalado original (y los recursos relacionados) y el estado del nodo de los nodos eliminados.

Lo siguiente le guiará a través del proceso de actualización del tamaño de VM y el sistema operativo de las VM del tipo de nodo no principal de un clúster de ejemplo con durabilidad Silver, respaldado por un solo conjunto de escalado con cinco nodos que se usa como tipo de nodo secundario. El tipo de nodo principal con los servicios del sistema de Service Fabric permanecerá intacto. Actualizaremos el tipo de nodo no principal:

  • Del tamaño de VM Standard_D2_V2 a Standard D4_V2 y
  • Desde el sistema operativo de máquina virtual Windows Server 2019 Datacenter a Windows Server 2022 Datacenter.

Advertencia

Antes de intentar este procedimiento en un clúster de producción, se recomienda que revise atentamente las plantillas de ejemplo y compruebe el proceso en un clúster de prueba.

No intente un procedimiento de escalado vertical del tipo de nodo no principal si el estado del clúster es incorrecto, ya que esto solo desestabilizará el clúster. Usaremos las plantillas de implementación de Azure paso a paso que se usan en la guía Escalado vertical de un tipo de nodo principal del clúster de Service Fabric. Sin embargo, los modificaremos para que no sean específicos de los tipos de nodo principal. Las plantillas están disponibles en GitHub.

Configuración del clúster de prueba

Configuremos el clúster de prueba inicial de Service Fabric. En primer lugar, descargue las plantillas de muestra de Azure Resource Manager que usaremos para completar este escenario.

A continuación, inicie sesión en la cuenta de Azure.

# Sign in to your Azure account
Login-AzAccount -SubscriptionId "<subscription ID>"

A continuación, abra el archivo parameters.json y actualice el valor de clusterName a algo único (en Azure).

Los comandos siguientes le guiarán a lo largo de la generación de un nuevo certificado autofirmado y la implementación del clúster de prueba. Si ya tiene un certificado que le gustaría usar, vaya a Uso de un certificado existente para implementar el clúster.

Generación de un certificado autofirmado e implementación del clúster

En primer lugar, asigne las variables que necesitará para la implementación del clúster de Service Fabric. Ajuste los valores de resourceGroupName, certSubjectName, parameterFilePath y templateFilePath para su entorno y cuenta específicos:

# Assign deployment variables
$resourceGroupName = "sftestupgradegroup"
$certOutputFolder = "c:\certificates"
$certPassword = "Password!1" | ConvertTo-SecureString -AsPlainText -Force
$certSubjectName = "sftestupgrade.southcentralus.cloudapp.azure.com"
$parameterFilePath = "C:\parameters.json"
$templateFilePath = "C:\Initial-TestClusterSetup.json"

Nota:

Asegúrese de que la ubicación certOutputFolder existe en el equipo local antes de ejecutar el comando para implementar un nuevo clúster de Service Fabric. A continuación, implemente el clúster de prueba de Service Fabric:

# Deploy the initial test cluster
New-AzServiceFabricCluster `
    -ResourceGroupName $resourceGroupName `
    -CertificateOutputFolder $certOutputFolder `
    -CertificatePassword $certPassword `
    -CertificateSubjectName $certSubjectName `
    -TemplateFile $templateFilePath `
    -ParameterFile $parameterFilePath

Una vez finalizada la implementación, busque el archivo .pfx ($certPfx) en la máquina local e impórtelo al almacén de certificados:

cd c:\certificates
$certPfx = ".\sftestupgradegroup20200312121003.pfx"
Import-PfxCertificate `
     -FilePath $certPfx `
     -CertStoreLocation Cert:\CurrentUser\My `
     -Password (ConvertTo-SecureString Password!1 -AsPlainText -Force)

La operación devolverá la huella digital de certificado, que puede usar ahora para conectarse al nuevo clúster y comprobar su estado de mantenimiento. (Omita la sección siguiente, que es un enfoque alternativo a la implementación del clúster).

Uso de un certificado existente para implementar el clúster

También puede usar un certificado de Azure Key Vault existente para implementar el clúster de prueba. Para ello, necesitará obtener referencias a su instancia de Key Vault y huella digital de certificado.

# Key Vault variables
$certUrlValue = "https://sftestupgradegroup.vault.azure.net/secrets/sftestupgradegroup20200309235308/dac0e7b7f9d4414984ccaa72bfb2ea39"
$sourceVaultValue = "/subscriptions/########-####-####-####-############/resourceGroups/sftestupgradegroup/providers/Microsoft.KeyVault/vaults/sftestupgradegroup"
$thumb = "BB796AA33BD9767E7DA27FE5182CF8FDEE714A70"

A continuación, designe un nombre del grupo de recursos para el clúster y establezca las ubicaciones templateFilePath y parameterFilePath:

Nota:

El grupo de recursos designado ya debe existir y debe estar ubicado en la misma región que el Key Vault.

$resourceGroupName = "sftestupgradegroup"
$templateFilePath = "C:\Initial-TestClusterSetup.json"
$parameterFilePath = "C:\parameters.json"

Finalmente, ejecute el comando siguiente para implementar el clúster de prueba inicial:

# Deploy the initial test cluster
New-AzResourceGroupDeployment `
    -ResourceGroupName $resourceGroupName `
    -TemplateFile $templateFilePath `
    -TemplateParameterFile $parameterFilePath `
    -CertificateThumbprint $thumb `
    -CertificateUrlValue $certUrlValue `
    -SourceVaultValue $sourceVaultValue `
    -Verbose

Conexión al nuevo clúster y comprobación del estado de mantenimiento

Conéctese al clúster y asegúrese de que los cinco nodos sean correctos (reemplace las variables clusterName y thumb por sus propios valores):

# Connect to the cluster
$clusterName = "sftestupgrade.southcentralus.cloudapp.azure.com:19000"
$thumb = "BB796AA33BD9767E7DA27FE5182CF8FDEE714A70"
Connect-ServiceFabricCluster `
    -ConnectionEndpoint $clusterName `
    -KeepAliveIntervalInSec 10 `
    -X509Credential `
    -ServerCertThumbprint $thumb  `
    -FindType FindByThumbprint `
    -FindValue $thumb `
    -StoreLocation CurrentUser `
    -StoreName My
# Check cluster health
Get-ServiceFabricClusterHealth

Con eso, estamos listos para comenzar el procedimiento de actualización.

Implementación de un nuevo tipo de nodo no principal con un conjunto de escalado actualizado

Para actualizar (escalar verticalmente) un tipo de nodo, primero tendremos que implementar un nuevo tipo de nodo respaldado por un nuevo conjunto de escalado y recursos de apoyo. El nuevo conjunto de escalado se marcará como no principal (isPrimary: false), al igual que el conjunto de escalado original. Si desea escalar verticalmente un tipo de nodo principal, consulte Escalado vertical del tipo de nodo principal de un clúster de Service Fabric. Los recursos creados en la sección siguiente se convertirán en última instancia en el nuevo tipo de nodo del clúster y se eliminarán los recursos de tipo de nodo originales.

Actualización de la plantilla de clúster con el conjunto de escalado actualizado

Estas son las modificaciones sección por sección de la plantilla de implementación del clúster original para agregar un nuevo tipo de nodo y recursos de apoyo.

La mayoría de los cambios necesarios para este paso ya se han realizado automáticamente en el archivo de plantilla Step1-AddPrimaryNodeType.json. Sin embargo, se debe realizar un cambio adicional para que el archivo de plantilla funcione para los tipos de nodo no principales. En las siguientes secciones se explicarán estos cambios en detalle, y se hará una llamada cuando deba hacer un cambio.

Nota

Asegúrese de usar nombres que sean únicos del tipo de nodo original, el conjunto de escalado, el equilibrador de carga, la dirección IP pública y la subred del tipo de nodo no principal original, ya que estos recursos se eliminarán en un paso posterior del proceso.

Creación de una nueva subred en la red virtual existente

{
    "name": "[variables('subnet1Name')]",
    "properties": {
        "addressPrefix": "[variables('subnet1Prefix')]"
    }
}

Creación de una nueva dirección IP pública con un valor de domainNameLabel único

{
    "apiVersion": "[variables('publicIPApiVersion')]",
    "type": "Microsoft.Network/publicIPAddresses",
    "name": "[concat(variables('lbIPName'),'-',variables('vmNodeType1Name'))]",
    "location": "[variables('computeLocation')]",
    "properties": {
        "dnsSettings": {
            "domainNameLabel": "[concat(variables('dnsName'),'-','nt1')]"
        },
        "publicIPAllocationMethod": "Dynamic"
    },
    "tags": {
        "resourceType": "Service Fabric",
        "clusterName": "[parameters('clusterName')]"
    }
}

Creación de un nuevo equilibrador de carga para la dirección IP pública

"dependsOn": [
    "[concat('Microsoft.Network/publicIPAddresses/',concat(variables('lbIPName'),'-',variables('vmNodeType1Name')))]"
]

Creación de un nuevo conjunto de escalado de máquinas virtuales (con la máquina virtual actualizada y las SKU del sistema operativo)

Referencia del tipo de nodo

"nodeTypeRef": "[variables('vmNodeType1Name')]"

SKU de la máquina virtual

"sku": {
    "name": "[parameters('vmNodeType1Size')]",
    "capacity": "[parameters('nt1InstanceCount')]",
    "tier": "Standard"
}

SKU del sistema operativo

"imageReference": {
    "publisher": "[parameters('vmImagePublisher1')]",
    "offer": "[parameters('vmImageOffer1')]",
    "sku": "[parameters('vmImageSku1')]",
    "version": "[parameters('vmImageVersion1')]"
}

Además, asegúrese de que incluye las extensiones adicionales necesarias para la carga de trabajo.

Incorporación de un nuevo tipo de nodo no principal al clúster

Ahora que el nuevo tipo de nodo (vmNodeType1Name) tiene su propio nombre, subred, dirección IP, equilibrador de carga y conjunto de escalado, puede volver a usar todas las demás variables del tipo de nodo original (por ejemplo, nt0applicationEndPort, nt0applicationStartPort y nt0fabricTcpGatewayPort).

En el archivo de plantilla existente, el parámetro isPrimary se establece en true para la guía Escalado vertical de un tipo de nodo principal del clúster de Service Fabric. Cambie isPrimary a false para el tipo de nodo no principal:

"name": "[variables('vmNodeType1Name')]",
"applicationPorts": {
    "endPort": "[variables('nt0applicationEndPort')]",
    "startPort": "[variables('nt0applicationStartPort')]"
},
"clientConnectionEndpointPort": "[variables('nt0fabricTcpGatewayPort')]",
"durabilityLevel": "Bronze",
"ephemeralPorts": {
    "endPort": "[variables('nt0ephemeralEndPort')]",
    "startPort": "[variables('nt0ephemeralStartPort')]"
},
"httpGatewayEndpointPort": "[variables('nt0fabricHttpGatewayPort')]",
"isPrimary": false,
"reverseProxyEndpointPort": "[variables('nt0reverseProxyEndpointPort')]",
"vmInstanceCount": "[parameters('nt1InstanceCount')]"

Una vez que haya implementado todos los cambios en los archivos de plantilla y de parámetros, continúe con la sección siguiente para adquirir las referencias de Key Vault e implementar las actualizaciones en el clúster.

Obtener las referencias de Key Vault

Para implementar la configuración actualizada, necesitará varias referencias al certificado de clúster almacenado en Key Vault. La forma más fácil de encontrar estos valores es desde Azure Portal. Necesitará:

  • La dirección URL de Key del certificado del clúster. En la instancia de Key Vault de Azure Portal, seleccione Certificados>el certificado que quiera>Identificador secreto:

    $certUrlValue="https://sftestupgradegroup.vault.azure.net/secrets/sftestupgradegroup20200309235308/dac0e7b7f9d4414984ccaa72bfb2ea39"
    
  • La huella digital del certificado del clúster. (Probablemente ya lo tenga si se conectó al clúster original para comprobar su estado de mantenimiento). En la misma hoja de certificado (Certificados>el certificado que quiera) en Azure Portal, copie la huella digital X.509 SHA-1 (en formato hexadecimal) :

    $thumb = "BB796AA33BD9767E7DA27FE5182CF8FDEE714A70"
    
  • Identificador de recurso de Key Vault. En la instancia de Key Vault en Azure Portal, seleccione Propiedades>Id. de recurso:

    $sourceVaultValue = "/subscriptions/########-####-####-####-############/resourceGroups/sftestupgradegroup/providers/Microsoft.KeyVault/vaults/sftestupgradegroup"
    

Implementar la plantilla actualizada

Ajuste templateFilePath según sea necesario y ejecute el siguiente comando:

# Deploy the new node type and its resources
$templateFilePath = "C:\Step1-AddPrimaryNodeType.json"
New-AzResourceGroupDeployment `
    -ResourceGroupName $resourceGroupName `
    -TemplateFile $templateFilePath `
    -TemplateParameterFile $parameterFilePath `
    -CertificateThumbprint $thumb `
    -CertificateUrlValue $certUrlValue `
    -SourceVaultValue $sourceVaultValue `
    -Verbose

Una vez finalizada la implementación, vuelva a comprobar el estado del clúster y asegúrese de que todos los nodos de ambos tipos de nodo tengan un estado correcto.

Get-ServiceFabricClusterHealth

Migración de las cargas de trabajo al nuevo tipo de nodo

Espere hasta que todas las aplicaciones se muevan al nuevo tipo de nodo y estén en buen estado.

Deshabilitación de los nodos del conjunto de escalado de tipo de nodo original

Una vez que todos los nodos de inicialización hayan migrado al nuevo conjunto de escalado, podrá deshabilitar los nodos del conjunto de escalado original.

# Disable the nodes in the original scale set.
$nodeType = "nt0vm"
$nodes = Get-ServiceFabricNode
Write-Host "Disabling nodes..."
foreach($node in $nodes)
{
  if ($node.NodeType -eq $nodeType)
  {
    $node.NodeName
    Disable-ServiceFabricNode -Intent RemoveNode -NodeName $node.NodeName -Force
  }
}

Use Service Fabric Explorer para supervisar la progresión de los nodos del conjunto de escalado original del estado Desactivando a Deshabilitado. Espere a que todos los nodos lleguen al estado Deshabilitado.

Detener datos en los nodos deshabilitados

Ahora puede detener los datos en los nodos deshabilitados.

# Stop data on the disabled nodes.
foreach($node in $nodes)
{
  if ($node.NodeType -eq $nodeType)
  {
    $node.NodeName
    Start-ServiceFabricNodeTransition -Stop -OperationId (New-Guid) -NodeInstanceId $node.NodeInstanceId -NodeName $node.NodeName -StopDurationInSeconds 10000
  }
}

Eliminación del tipo de nodo original y limpieza de sus recursos

Estamos preparados para quitar el tipo de nodo original y sus recursos asociados para concluir el procedimiento de escalado vertical.

Quitar el conjunto de escalado original

En primer lugar, quite el conjunto de escalado de respaldo del tipo de nodo.

$scaleSetName = "nt0vm"
$scaleSetResourceType = "Microsoft.Compute/virtualMachineScaleSets"
Remove-AzResource -ResourceName $scaleSetName -ResourceType $scaleSetResourceType -ResourceGroupName $resourceGroupName -Force

Eliminación de los recursos Equilibrador de carga e IP originales

Ahora puede eliminar los recursos Equilibrador de carga e IP originales. En este paso también actualizará el nombre DNS.

Nota:

Este paso es opcional si ya usa una IP pública de la SKU Estándar y un equilibrador de carga. En este caso puede tener varios conjuntos de escalado o tipos de nodos en el mismo equilibrador de carga. Ejecute los siguientes comandos, modificando el valor $lbname según sea necesario.

# Delete the original IP and load balancer resources
$lbName = "LB-sftestupgrade-nt0vm"
$lbResourceType = "Microsoft.Network/loadBalancers"
$ipResourceType = "Microsoft.Network/publicIPAddresses"
$oldPublicIpName = "PublicIP-LB-FE-nt0vm"
$newPublicIpName = "PublicIP-LB-FE-nt1vm"
$oldPublicIP = Get-AzPublicIpAddress -Name $oldPublicIpName  -ResourceGroupName $resourceGroupName
$nonPrimaryDNSName = $oldNonPrimaryPublicIP.DnsSettings.DomainNameLabel
$nonPrimaryDNSFqdn = $oldNonPrimaryPublicIP.DnsSettings.Fqdn
Remove-AzResource -ResourceName $lbName -ResourceType $lbResourceType -ResourceGroupName $resourceGroupName -Force
Remove-AzResource -ResourceName $oldPublicIpName -ResourceType $ipResourceType -ResourceGroupName $resourceGroupName -Force
$PublicIP = Get-AzPublicIpAddress -Name $newPublicIpName  -ResourceGroupName $resourceGroupName
$PublicIP.DnsSettings.DomainNameLabel = $nonPrimaryDNSName
$PublicIP.DnsSettings.Fqdn = $nonPrimaryDNSFqdn
Set-AzPublicIpAddress -PublicIpAddress $PublicIP

Eliminación del estado del nodo del tipo de nodo original

Los nodos de tipo de nodo originales ahora mostrarán Error para su Estado de mantenimiento. Quite su estado del nodo del clúster.

# Remove state of the obsolete nodes from the cluster
$nodeType = "nt0vm"
$nodes = Get-ServiceFabricNode
Write-Host "Removing node state..."
foreach($node in $nodes)
{
  if ($node.NodeType -eq $nodeType)
  {
    $node.NodeName
    Remove-ServiceFabricNodeState -NodeName $node.NodeName -Force
  }
}

Service Fabric Explorer debería reflejar ahora solo los cinco nodos del nuevo tipo de nodo (nt1vm), todos ellos con los valores de estado de mantenimientoAceptar. Corregiremos esto a continuación actualizando la plantilla para reflejar los cambios más recientes y volviendo a implementar.

Actualización de la plantilla de implementación para reflejar el tipo de nodo no principal recién escalado verticalmente

La mayoría de los cambios necesarios para este paso ya se han realizado automáticamente en el archivo de plantilla Step3-CleanupOriginalPrimaryNodeType.json. Sin embargo, se debe realizar un cambio adicional para que el archivo de plantilla funcione para los tipos de nodo no principales. En las siguientes secciones se explicarán estos cambios en detalle, y se hará una llamada cuando deba hacer un cambio.

Actualización del punto de conexión de administración del clúster

Actualice el clúster managementEndpoint en la plantilla de implementación para hacer referencia a la nueva dirección IP (mediante la actualización de vmNodeType0Name con vmNodeType1Name).

  "managementEndpoint": "[concat('https://',reference(concat(variables('lbIPName'),'-',variables('vmNodeType1Name'))).dnsSettings.fqdn,':',variables('nt0fabricHttpGatewayPort'))]",

Eliminación de la referencia de tipo de nodo original

Elimine la referencia del tipo de nodo original del recurso de Service Fabric en la plantilla de implementación.

En el archivo de plantilla existente, el parámetro isPrimary se establece en true para la guía Escalado vertical de un tipo de nodo principal del clúster de Service Fabric. Cambie isPrimary a false para el tipo de nodo no principal:

"name": "[variables('vmNodeType0Name')]",
"applicationPorts": {
    "endPort": "[variables('nt0applicationEndPort')]",
    "startPort": "[variables('nt0applicationStartPort')]"
},
"clientConnectionEndpointPort": "[variables('nt0fabricTcpGatewayPort')]",
"durabilityLevel": "Bronze",
"ephemeralPorts": {
    "endPort": "[variables('nt0ephemeralEndPort')]",
    "startPort": "[variables('nt0ephemeralStartPort')]"
},
"httpGatewayEndpointPort": "[variables('nt0fabricHttpGatewayPort')]",
"isPrimary": false,
"reverseProxyEndpointPort": "[variables('nt0reverseProxyEndpointPort')]",
"vmInstanceCount": "[parameters('nt0InstanceCount')]"

Configuración de las directivas de mantenimiento para omitir los errores existentes

Solo en el caso de los clústeres de durabilidad Silver y superior, actualice el recurso de clúster en la plantilla y configure directivas de mantenimiento para omitir el estado de la aplicación fabric:/System; para ello, agregue applicationDeltaHealthPolicies en las propiedades del recurso de clúster como se indica a continuación. La directiva siguiente omitirá los errores existentes, pero no permitirá nuevos errores de estado.

"upgradeDescription":  
{ 
 "forceRestart": false, 
 "upgradeReplicaSetCheckTimeout": "10675199.02:48:05.4775807", 
 "healthCheckWaitDuration": "00:05:00", 
 "healthCheckStableDuration": "00:05:00", 
 "healthCheckRetryTimeout": "00:45:00", 
 "upgradeTimeout": "12:00:00", 
 "upgradeDomainTimeout": "02:00:00", 
 "healthPolicy": { 
   "maxPercentUnhealthyNodes": 100, 
   "maxPercentUnhealthyApplications": 100 
 }, 
 "deltaHealthPolicy":  
 { 
   "maxPercentDeltaUnhealthyNodes": 0, 
   "maxPercentUpgradeDomainDeltaUnhealthyNodes": 0, 
   "maxPercentDeltaUnhealthyApplications": 0, 
   "applicationDeltaHealthPolicies":  
   { 
       "fabric:/System":  
       { 
           "defaultServiceTypeDeltaHealthPolicy":  
           { 
                   "maxPercentDeltaUnhealthyServices": 0 
           } 
       } 
   } 
 } 
}

Eliminación de recursos de apoyo para el tipo de nodo original

Elimine de la plantilla de ARM y el archivo de parámetros el resto de recursos que tengan relación con el tipo de nodo original. Elimine lo siguiente:

    "vmImagePublisher": {
      "value": "MicrosoftWindowsServer"
    },
    "vmImageOffer": {
      "value": "WindowsServer"
    },
    "vmImageSku": {
      "value": "2019-Datacenter"
    },
    "vmImageVersion": {
      "value": "latest"
    },

Implementación de la plantilla finalizada

Por último, implemente la plantilla de Azure Resource Manager modificada.

# Deploy the updated template file
$templateFilePath = "C:\Step3-CleanupOriginalPrimaryNodeType"
New-AzResourceGroupDeployment `
    -ResourceGroupName $resourceGroupName `
    -TemplateFile $templateFilePath `
    -TemplateParameterFile $parameterFilePath `
    -CertificateThumbprint $thumb `
    -CertificateUrlValue $certUrlValue `
    -SourceVaultValue $sourceVaultValue `
    -Verbose

Nota:

Este paso tardará un rato, habitualmente puede llegar a las dos horas. La actualización cambiará la configuración a InfrastructureService; por lo que es necesario reiniciar el nodo. En este caso, forceRestart se omite. El parámetro upgradeReplicaSetCheckTimeout especifica el tiempo máximo que Service Fabric espera a que una partición pase a un estado seguro, si aún no lo está. Una vez que se superan las comprobaciones de seguridad de todas las particiones de un nodo, Service Fabric continúa con la actualización en ese nodo. El valor del parámetro upgradeTimeout puede reducirse a 6 horas, pero debe usarse la seguridad máxima de 12 horas.

Una vez finalizada la implementación, compruebe en Azure Portal que el estado del recurso de Service Fabric es Listo. Compruebe que puede tener acceso al nuevo punto de conexión de Service Fabric Explorer, que el estado de mantenimiento del clúster es Aceptar y que las aplicaciones implementadas funcionan correctamente.

Así ha escalado verticalmente un tipo de nodo no principal del clúster.

Pasos siguientes