Memigrasikan kluster Service Fabric Anda ke dukungan zona ketersediaan

  • Artikel

Panduan ini menjelaskan cara memigrasikan kluster Service Fabric dari dukungan zona non-ketersediaan ke dukungan ketersediaan. Kami akan membawa Anda melalui berbagai opsi untuk migrasi. Kluster Service Fabric yang didistribusikan di seluruh Zona ketersediaan memastikan ketersediaan tinggi status kluster.

Anda dapat memigrasikan kluster terkelola dan non-terkelola. Keduanya dibahas dalam artikel ini.

Untuk kluster yang tidak dikelola, kami membahas dua skenario berbeda:

  • Memigrasikan kluster dengan load balancer SKU Standar dan sumber daya IP. Konfigurasi ini mendukung zona ketersediaan tanpa perlu membuat sumber daya baru.
  • Memigrasikan kluster dengan load balancer SKU Dasar dan sumber daya IP. Konfigurasi ini tidak mendukung zona ketersediaan dan memerlukan pembuatan sumber daya baru.

Lihat bagian yang sesuai di bawah setiap header untuk skenario kluster Service Fabric Anda.

Catatan

Manfaat mencakup jenis node utama di seluruh zona ketersediaan hanya terlihat untuk tiga zona dan bukan hanya dua. Ini berlaku untuk kluster terkelola dan tidak terkelola.

Templat sampel tersedia di templat zona ketersediaan lintas Service Fabric.

Prasyarat

Klaster yang dikelola Service Fabric

Wajib diisi:

Direkomendasikan:

  • SKU kluster harus bersifat Standar.
  • Jenis simpul primer harus memiliki setidaknya sembilan simpul untuk ketahanan terbaik, tetapi mendukung jumlah minimum sebanyak enam.
  • Jenis simpul sekunder harus memiliki setidaknya enam simpul untuk ketahanan terbaik, tetapi mendukung jumlah minimum sebanyak tiga.

Kluster yang tidak dikelola Service Fabric

Diperlukan: N/A.

Direkomendasikan:

  • Tingkat keandalan kluster diatur ke Platinum.
  • Satu sumber daya IP publik menggunakan SKU Standar.
  • Satu sumber daya load balancer menggunakan SKU Standar.
  • Grup keamanan jaringan (NSG) yang dirujuk oleh subnet tempat Anda menyebarkan Virtual Machine Scale Sets Anda.

Load balancer SKU Standar dan sumber daya IP yang ada

Tidak ada prasyarat untuk skenario ini, karena mengasumsikan Anda memiliki sumber daya yang diperlukan yang ada.

Load balancer SKU dasar dan sumber daya IP

  • Load balancer baru menggunakan SKU Standar, berbeda dari load balancer SKU Dasar yang ada.
  • Sumber daya IP baru menggunakan SKU Standar, berbeda dari sumber daya IP SKU Dasar yang ada.

Catatan

Tidak dimungkinkan untuk meningkatkan sumber daya yang ada dari SKU Dasar ke SKU Standar, sehingga sumber daya baru diperlukan.

Persyaratan waktu henti

Kluster yang dikelola Service Fabric

Migrasi ke konfigurasi tangguh zona dapat menyebabkan hilangnya konektivitas eksternal secara singkat melalui load balancer, tetapi tidak akan memengaruhi kesehatan kluster. Hilangnya konektivitas eksternal terjadi ketika IP Publik baru perlu dibuat untuk membuat jaringan tahan terhadap kegagalan zona. Rencanakan migrasi yang sesuai.

Kluster yang tidak dikelola Service Fabric

Waktu henti untuk memigrasikan kluster yang tidak dikelola Service Fabric sangat bervariasi berdasarkan jumlah VM dan Domain Peningkatan (URI) di kluster Anda. ED adalah pengelompokan logis VM yang menentukan urutan peningkatan didorong ke VM di kluster Anda. Waktu henti juga dipengaruhi oleh mode peningkatan kluster Anda, yang menangani bagaimana tugas peningkatan untuk ED di kluster Anda diproses. Properti sfZonalUpgradeMode , yang mengontrol mode peningkatan, dibahas secara lebih rinci di bagian berikut.

Migrasi untuk kluster yang dikelola Service Fabric

Ikuti langkah-langkah dalam Memigrasikan kluster terkelola Service Fabric ke tangguh zona.

Opsi migrasi untuk kluster yang tidak dikelola Service Fabric

Opsi migrasi 1: aktifkan beberapa Zona Ketersediaan dalam satu Set Skala Komputer Virtual

Kapan menggunakan opsi ini

Solusi ini memungkinkan pengguna untuk menjangkau tiga Zona Ketersediaan dalam jenis node yang sama. Ini adalah topologi penyebaran yang direkomendasikan karena memungkinkan Anda untuk menyebarkan di seluruh zona ketersediaan sambil mempertahankan satu Set Skala Komputer Virtual.

Templat sampel lengkap tersedia di GitHub.

Anda harus menggunakan opsi ini ketika Anda memiliki kluster non-terkelola Service Fabric yang ada dengan load balancer SKU Standar dan Sumber Daya IP yang ingin Anda migrasikan. Jika kluster yang tidak dikelola yang ada memiliki sumber daya SKU Dasar, Anda akan melihat opsi migrasi SKU Dasar di bawah ini.

Cara memigrasikan kluster yang tidak dikelola Service Fabric Anda dengan load balancer SKU Standar dan sumber daya IP yang ada

Untuk mengaktifkan zona pada Set Skala Komputer Virtual:

Sertakan tiga nilai berikut dalam sumber daya Set Skala Komputer Virtual:

  • Nilai pertama adalah zones properti , yang menentukan Zona Ketersediaan yang ada di Set Skala Komputer Virtual.

  • Nilai kedua adalah properti singlePlacementGroup, yang harus diatur ke true. Set skala yang membentang di tiga Zona Ketersediaan dapat menskalakan hingga 300 VM bahkan dengan singlePlacementGroup = true.

  • Nilai ketiga adalah zoneBalance, yang memastikan keseimbangan zona yang ketat. Nilai ini harus true. Nilai ini memastikan bahwa distribusi VM di seluruh zona seimbang, artinya ketika satu zona turun, dua zona lainnya memiliki cukup VM untuk menjaga kluster tetap berjalan.

    Kluster dengan distribusi VM yang tidak seimbang mungkin tidak dapat bertahan pada skenario zona tidak berfungsi karena zona tersebut mungkin memiliki mayoritas VM. Distribusi VM yang tidak seimbang di seluruh zona juga akan menyebabkan masalah penempatan layanan dan pembaruan infrastruktur yang macet. Baca selengkapnya tentang zoneBalancing.

Anda tidak perlu mengonfigurasi penggantian FaultDomain dan UpgradeDomain.

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

Catatan

  • Kluster Service Fabric harus memiliki setidaknya satu jenis node primer. Tingkat durabilitas jenis node primer harus Silver atau lebih tinggi.
  • Zona ketersediaan yang mencakup Set Skala Komputer Virtual harus dikonfigurasi dengan setidaknya tiga Zona Ketersediaan, terlepas dari tingkat durabilitasnya.
  • Zona ketersediaan yang mencakup Set Skala Komputer Virtual dengan durabilitas Silver atau yang lebih tinggi harus memiliki setidaknya 15 VM.
  • Zona ketersediaan yang mencakup Set Skala Komputer Virtual dengan durabilitas Perunggu harus memiliki setidaknya enam VM.
Mengaktifkan dukungan untuk beberapa zona di jenis node Service Fabric

Untuk mendukung beberapa zona ketersediaan, jenis node Service Fabric harus diaktifkan.

  • Nilai pertama adalah multipleAvailabilityZones, yang harus diatur ke true untuk jenis node tersebut.

  • Nilai kedua adalah sfZonalUpgradeMode dan bersifat opsional. Properti ini tidak dapat dimodifikasi jika jenis node dengan beberapa zona ketersediaan sudah ada di kluster. Properti ini mengontrol pengelompokan logis VM dalam EKSEKUSI.

    • Jika nilai ini diatur ke Parallel: VM di bawah jenis node tersebut dikelompokkan ke dalam UD dan mengabaikan info zona dalam lima UD. Pengaturan ini menyebabkan UD di semua zona ditingkatkan pada saat yang sama. Meskipun mode penyebaran ini lebih cepat untuk peningkatan, kami tidak merekomendasikannya karena bertentangan dengan pedoman SDP, yang menyatakan bahwa pembaruan harus diterapkan ke satu zona pada satu waktu.

    • Jika nilai dihilangkan atau diatur ke Hierarchical: VM akan dikelompokkan untuk mencerminkan distribusi zona dalam 15 UD. Masing-masing dari tiga zona memiliki lima UD. Nilai ini memastikan zona diperbarui satu per satu, pindah ke zona berikutnya hanya setelah menyelesaikan lima UD dalam zona pertama. Proses pembaruan lebih aman untuk kluster dan aplikasi pengguna.

    Properti ini hanya menentukan perilaku peningkatan untuk aplikasi Service Fabric dan peningkatan kode. Peningkatan Set Skala Komputer Virtual yang mendasar masih paralel di semua Zona Ketersediaan. Properti ini tidak mempengaruhi distribusi UD untuk jenis node yang tidak memiliki beberapa zona yang diaktifkan.

  • Nilai ketiga adalah , bersifat vmssZonalUpgradeModeopsional dan dapat diperbarui kapan saja. Properti ini mendefinisikan skema peningkatan untuk Virtual Machine Scale Set agar terjadi secara paralel atau berurutan di seluruh Zona Ketersediaan.

    • Jika nilai ini diatur ke Parallel: Semua pembaruan set skala terjadi secara paralel di semua zona. Mode penyebaran ini lebih cepat untuk peningkatan, sehingga kami tidak merekomendasikannya karena bertentangan dengan pedoman SDP, yang menyatakan bahwa pembaruan harus diterapkan ke satu zona pada satu waktu.
    • Jika nilai ini dihilangkan atau disetel ke Hierarchical: Nilai ini memastikan zona diperbarui satu per satu, pindah ke zona berikutnya hanya setelah menyelesaikan lima UD dalam zona pertama. Proses pembaruan ini lebih aman untuk kluster dan aplikasi pengguna.

Penting

Versi API sumber daya kluster Service Fabric harus 2020-12-01-pratinjau atau yang lebih baru.

Versi kode kluster harus setidaknya 8.1.321 atau yang lebih baru.

{
  "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
      }
    ]
  }
}

Catatan

  • IP Publik dan sumber daya load balancer harus menggunakan SKU Standar seperti yang dijelaskan sebelumnya dalam artikel.
  • Properti multipleAvailabilityZones pada jenis node hanya dapat ditentukan ketika jenis node dibuat dan tidak dapat dimodifikasi nanti. Jenis node yang ada tidak dapat dikonfigurasi dengan properti ini.
  • Ketika sfZonalUpgradeMode dihilangkan atau diatur ke Hierarchical, penerapan kluster dan aplikasi lebih lambat karena ada lebih banyak domain peningkatan dalam kluster. Penting untuk menyesuaikan batas waktu kebijakan peningkatan dengan benar untuk memperhitungkan durasi waktu peningkatan yang diperlukan untuk 15 domain peningkatan. Kebijakan peningkatan untuk aplikasi dan kluster harus diperbarui untuk memastikan penerapan tidak melebihi batas waktu penerapan Azure Resource Service selama 12 jam. Artinya, bahwa penerapan tidak boleh memakan waktu lebih dari 12 jam untuk 15 UD (artinya, tidak boleh memakan waktu lebih dari 40 menit untuk setiap UD).
  • Atur tingkat reliabilitas kluster ke Platinum untuk memastikan kluster bertahan dalam skenario satu zona tidak berfungsi.
  • Meningkatkan DurabilityLevel untuk nodetype dengan multipleAvailabilityZones, tidak didukung. Buat jenis node baru dengan durabilitas yang lebih tinggi sebagai gantinya.
  • SF hanya mendukung 3 AvailabilityZones. Angka yang lebih tinggi saat ini tidak didukung.

Tip

Sebaiknya atur sfZonalUpgradeMode ke Hierarchical atau dihilangkan. Penerapan akan mengikuti distribusi zona VM yang berdampak pada jumlah replika dan/atau instans yang lebih kecil sehingga lebih aman. Gunakan sfZonalUpgradeMode lalu atur ke Parallel jika kecepatan penerapan diprioritaskan atau hanya beban kerja stateless yang dijalankan pada jenis node dengan beberapa Zona Ketersediaan. Hal ini menyebabkan UD berjalan terjadi secara paralel di semua Zona Ketersediaan.

Bermigrasi ke jenis node dengan beberapa Zona Ketersediaan

Untuk semua skenario migrasi, Anda perlu menambahkan jenis node baru yang mendukung beberapa Zona Ketersediaan. Jenis node yang ada tidak dapat dimigrasikan untuk mendukung beberapa zona. Artikel Menskalakan jenis node primer kluster Service Fabric mencakup langkah-langkah terperinci untuk menambahkan jenis node baru dan sumber daya lain yang diperlukan untuk jenis node baru, seperti IP dan sumber daya load balancer. Artikel tersebut juga menjelaskan cara menghentikan jenis node yang ada setelah jenis node dengan beberapa Zona Ketersediaan ditambahkan ke kluster.

  • Migrasi dari jenis node yang menggunakan load balancer dasar dan sumber daya IP: Proses ini sudah dijelaskan dalam sub-bagian di bawah ini untuk solusi dengan satu jenis node per Zona Ketersediaan.

    Untuk jenis node baru, satu-satunya perbedaan adalah hanya ada satu Set Skala Komputer Virtual dan satu jenis node untuk semua Zona Ketersediaan, bukan satu masing-masing per Zona Ketersediaan.

  • Migrasi dari jenis node yang menggunakan load balancer SKU Standar dan sumber daya IP dengan NSG: Ikuti prosedur yang sama yang dijelaskan sebelumnya. Namun, Anda tidak perlu menambahkan load balancer, IP, dan sumber daya NSG baru. Sumber daya yang sama dapat digunakan kembali dalam jenis node baru.

Jika Anda mengalami masalah, hubungi dukungan untuk mendapatkan bantuan.

Opsi migrasi 2: menyebarkan zona dengan menyematkan satu Set Skala Komputer Virtual ke setiap zona

Kapan menggunakan opsi ini

Penerapan ini adalah konfigurasi yang tersedia secara umum saat ini.

Untuk menjangkau kluster Service Fabric di seluruh Zona Ketersediaan, Anda harus membuat jenis node primer di setiap Zona Ketersediaan yang didukung oleh wilayah tersebut. Hal ini akan mendistribusikan node turunan secara merata di setiap jenis node primer.

Topologi yang disarankan untuk jenis node primer memerlukan sumber daya yang diuraikan di bawah ini:

  • Tiga jenis node ditandai sebagai primer
    • Setiap jenis node harus dipetakan ke Virtual Machine Scale Set sendiri yang terletak di zona yang berbeda.
    • Setiap Set Skala Komputer Virtual harus memiliki setidaknya lima node (Durabilitas Perak).

Anda harus menggunakan opsi ini ketika Anda memiliki kluster non-terkelola Service Fabric yang ada dengan load balancer SKU Standar dan Sumber Daya IP yang ingin Anda migrasikan. Jika kluster yang tidak dikelola yang ada memiliki sumber daya SKU Dasar, Anda akan melihat opsi migrasi SKU Dasar di bawah ini.

Cara memigrasikan kluster yang tidak dikelola Service Fabric Anda dengan load balancer SKU Standar dan sumber daya IP yang ada

Mengaktifkan zona pada Set Skala Komputer Virtual

Untuk mengaktifkan zona pada Set Skala Komputer Virtual, sertakan tiga nilai berikut dalam sumber daya Set Skala Komputer Virtual:

  • Nilai pertama adalah zones properti , yang menentukan Zona Ketersediaan tempat Set Skala Komputer Virtual disebarkan.
  • Nilai kedua adalah properti singlePlacementGroup, yang harus diatur ke true.
  • Nilai ketiga adalah faultDomainOverride properti dalam ekstensi Service Fabric Virtual Machine Scale Set. Properti ini hanya boleh mencakup zona tempat Set Skala Komputer Virtual ini akan ditempatkan. Contoh: "faultDomainOverride": "az1". Semua sumber daya Virtual Machine Scale Set harus ditempatkan di wilayah yang sama karena kluster Azure Service Fabric tidak memiliki dukungan lintas wilayah.
{
  "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"
          }
        }
      ]
    }
  }
}
Mengaktifkan beberapa jenis node primer dalam sumber daya kluster Service Fabric

Untuk mengatur satu atau lebih jenis node sebagai primer dalam sumber daya kluster, atur properti isPrimary ke true. Saat menerapkan kluster Service Fabric di seluruh Zona Ketersediaan, Anda harus memiliki tiga jenis node di zona yang berbeda.

{
  "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')]"
    }
  ]
}

Jika Anda mengalami masalah, hubungi dukungan untuk mendapatkan bantuan.

Opsi migrasi: Kluster non-terkelola Service Fabric dengan load balancer SKU Dasar dan sumber daya IP

Kapan menggunakan opsi ini

Anda harus menggunakan opsi ini ketika Anda memiliki kluster non-terkelola Service Fabric yang ada dengan load balancer SKU Dasar dan Sumber Daya IP yang ingin Anda migrasikan. Jika kluster yang tidak dikelola yang ada memiliki sumber daya SKU Standar, Anda akan melihat opsi migrasi di atas. Jika Anda belum membuat kluster yang tidak dikelola tetapi tahu bahwa Anda ingin kluster tersebut diaktifkan AZ, buat dengan sumber daya SKU Standar.

Cara memigrasikan kluster non-terkelola Service Fabric Anda dengan load balancer SKU Dasar dan sumber daya IP

Untuk melakukan migrasi kluster yang menggunakan load balancer dan IP dengan SKU dasar, Anda harus terlebih dahulu membuat load balancer yang sepenuhnya baru dan sumber daya IP yang menggunakan SKU standar. Tidak dimungkinkan untuk memperbarui sumber daya ini.

Referensi load balancer dan IP baru di jenis node lintas Zona Ketersediaan baru yang ingin Anda gunakan. Dalam contoh sebelumnya, tiga sumber daya Virtual Machine Scale Set baru ditambahkan di zona 1, 2, dan 3. Virtual Machine Scale Sets ini mereferensikan load balancer dan IP yang baru dibuat dan ditandai sebagai jenis node utama dalam sumber daya kluster Service Fabric.

  1. Untuk memulai, tambahkan sumber daya baru ke templat Azure Resource Manager yang sudah ada. Sumber daya ini meliputi:

    • Sumber daya IP publik menggunakan SKU Standar
    • Sumber daya load balancer yang menggunakan SKU Standar
    • NSG yang dirujuk oleh subnet tempat Anda menyebarkan Virtual Machine Scale Sets
    • Tiga jenis node ditandai sebagai primer
      • Setiap jenis node harus dipetakan ke Virtual Machine Scale Set sendiri yang terletak di zona yang berbeda.
      • Setiap Set Skala Komputer Virtual harus memiliki setidaknya lima node (Durabilitas Perak).

    Contoh sumber daya ini dapat ditemukan di templat sampel.

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

  2. Setelah sumber daya selesai diterapkan, Anda dapat menonaktifkan node pada jenis node primer dari kluster asli. Ketika node dinonaktifkan, layanan sistem bermigrasi ke jenis node primer baru yang Anda terapkan sebelumnya.

    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. Setelah semua node dinonaktifkan, layanan sistem akan berjalan pada jenis node primer, yang tersebar di seluruh zona. Anda kemudian dapat menghapus node yang dinonaktifkan dari kluster. Setelah node dihapus, Anda dapat menghapus ip asli, load balancer, dan sumber daya Virtual Machine Scale Set.

    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. Selanjutnya, hapus referensi ke sumber daya ini dari templat Resource Manager yang telah Anda terapkan.

  5. Terakhir, perbarui nama DNS dan IP publik.

$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

Jika Anda mengalami masalah, hubungi dukungan untuk mendapatkan bantuan.

Langkah berikutnya