Service Fabric 클러스터를 가용성 영역 지원으로 마이그레이션

아티클
04/27/2024

이 가이드에서는 Service Fabric 클러스터를 비가용성 영역 지원에서 가용성 지원으로 마이그레이션하는 방법을 설명합니다. 다양한 마이그레이션 옵션을 안내해 드리겠습니다. 가용성 영역에 분산된 Service Fabric 클러스터는 클러스터 상태의 고가용성을 보장합니다.

관리형 클러스터와 비관리형 클러스터를 모두 마이그레이션할 수 있습니다. 이 문서에서는 둘 다 다룹니다.

관리되지 않는 클러스터의 경우 두 가지 시나리오를 토론합니다.

표준 SKU 부하 분산 장치 및 IP 리소스를 사용하여 클러스터를 마이그레이션합니다. 이 구성은 새 리소스를 만들 필요 없이 가용성 영역을 지원합니다.
기본 SKU 부하 분산 장치 및 IP 리소스를 사용하여 클러스터를 마이그레이션합니다. 이 구성은 가용성 영역을 지원하지 않으며 새 리소스를 만들어야 합니다.

Service Fabric 클러스터 시나리오에 대한 각 헤더 아래의 해당 섹션을 참조하세요.

참고 항목

가용성 영역에서 주 노드 유형을 확장하는 이점은 두 영역이 아닌 세 개의 영역에 대해서만 볼 수 있습니다. 이는 관리형 클러스터와 비관리형 클러스터 모두에 해당됩니다.

샘플 템플릿은 Service Fabric 교차 가용성 영역 템플릿에서 사용할 수 있습니다.

필수 조건

Service Fabric 관리형 클러스터

필수:

표준 SKU 클러스터.
해당 지역에 있는 세 개의 가용성 영역.

권장:

클러스터 SKU는 표준이어야 합니다.
주 노드 유형에는 최상의 복원력을 위해 9개 이상의 노드가 있어야 하지만 최소 6개 노드를 지원합니다.
보조 노드 유형에는 최상의 복원력을 위해 6개 이상의 노드가 있어야 하지만 최소 3개 노드를 지원합니다.

Service Fabric 비관리형 클러스터

필수: 해당 없음.

권장:

클러스터 안정성 수준이 Platinum로 설정됩니다.
표준 SKU를 사용하는 단일 공용 IP 리소스.
표준 SKU를 사용하는 단일 부하 분산 장치 리소스.
Virtual Machine Scale Sets를 배포하는 서브넷에서 참조하는 NSG(네트워크 보안 그룹).

기존 표준 SKU 부하 분산 장치 및 IP 리소스

이 시나리오에서는 기존 필수 리소스가 있다고 가정하므로 필수 조건이 없습니다.

기본 SKU 부하 분산 장치 및 IP 리소스

기존 기본 SKU 부하 분산 장치와는 다른 표준 SKU를 사용하는 새로운 부하 분산 장치입니다.
기존 기본 SKU IP 리소스와는 다른 표준 SKU를 사용하는 새로운 IP 리소스입니다.

참고 항목

기존 리소스를 기본 SKU에서 표준 SKU로 업그레이드할 수 없으므로 새 리소스가 필요합니다.

가동 중지 시간 요구 사항

Service Fabric 관리형 클러스터

영역 복원 구성으로 마이그레이션하면 부하 분산 장치를 통해 외부 연결이 잠시 끊어질 수 있지만 클러스터 상태에는 영향을 미치지 않습니다. 외부 연결 끊김은 영역 오류에 대한 네트워킹 복원력을 높이기 위해 새 공용 IP를 만들어야 할 때 발생합니다. 이에 따라 마이그레이션을 계획합니다.

Service Fabric 비관리형 클러스터

Service Fabric 비관리형 클러스터 마이그레이션에 대한 가동 중지 시간은 클러스터의 VM 및 UD(업그레이드 도메인) 수에 따라 크게 다릅니다. UD는 업그레이드가 클러스터의 VM에 푸시되는 순서를 결정하는 VM의 논리적 그룹입니다. 가동 중지 시간은 클러스터의 UD에 대한 업그레이드 작업이 처리되는 방식을 처리하는 클러스터의 업그레이드 모드에 의해서도 영향을 받습니다. 업그레이드 모드를 제어하는 sfZonalUpgradeMode 속성은 다음 섹션에서 더 자세히 설명됩니다.

Service Fabric 관리형 클러스터 마이그레이션

복원력이 있는 영역으로 Service Fabric 관리형 클러스터 마이그레이션의 단계를 따릅니다.

Service Fabric 비관리형 클러스터에 대한 마이그레이션 옵션

마이그레이션 옵션 1: 단일 가상 머신 확장 집합에서 여러 가용성 영역을 사용하도록 설정합니다.

이 옵션을 사용해야 하는 경우

이 솔루션을 사용하면 사용자가 동일한 노드 형식의 세 가용성 영역을 포괄할 수 있습니다. 이는 단일 가상 머신 확장 집합을 유지하면서 가용성 영역에 배포할 수 있도록 하는 권장되는 배포 토폴로지입니다.

GitHub에서 전체 샘플 템플릿을 사용할 수 있습니다.

마이그레이션하려는 표준 SKU 부하 분산 장치 및 IP 리소스가 포함된 기존 Service Fabric 비관리형 클러스터가 있는 경우 이 옵션을 사용해야 합니다. 기존 비관리형 클러스터에 기본 SKU 리소스가 있는 경우 아래 기본 SKU 마이그레이션 옵션이 표시됩니다.

기존 표준 SKU 부하 분산 장치 및 IP 리소스를 사용하여 Service Fabric 비관리형 클러스터를 마이그레이션하는 방법

가상 머신 확장 집합에서 영역을 사용하려면

가상 머신 확장 집합 리소스에 다음 세 가지 값을 포함합니다.

첫 번째 값은 가상 머신 확장 집합에 있는 가용성 영역을 지정하는 zones 속성입니다.
두 번째 값은 true로 설정해야 하는 singlePlacementGroup 속성입니다. 3개 가용성 영역에 걸쳐 있는 확장 집합은 singlePlacementGroup = true의 경우에도 300 Vm까지 확장할 수 있습니다.
세 번째 값은 zoneBalance이며, 엄격한 영역 분산을 보장합니다. 이 값은 true여야 합니다. 이렇게 하면 영역 간의 VM 배포가 불균형하지 않습니다. 즉, 한 영역이 중단되어도 다른 두 영역에는 클러스터를 계속 실행할 수 있는 충분한 Vm이 있습니다.

VM 분산이 불균형한 클러스터는 해당 영역에 대부분의 Vm이 있을 수 있기 때문에 영역 다운 시나리오에서 사용하지 못할 수 있습니다. 영역에서 VM 분산이 불균형하면 서비스 배치 관련 문제가 발생하고 인프라 업데이트가 중단될 수 있습니다. 자세한 내용은 zoneBalancing를 참조하세요.

FaultDomain 및 UpgradeDomain 재정의를 구성할 필요가 없습니다.

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

참고 항목

Service Fabric 클러스터에는 하나 이상의 주 노드 형식이 있어야 합니다. 주 노드 형식의 내구성 수준은 Silver 이상이어야 합니다.
가상 머신 확장 집합에 걸쳐 있는 가용성 영역은 내구성 수준에 관계없이 3개 이상의 가용성 영역을 구성해야 합니다.
Silver 이상 내구성의 가상 머신 확장 집합에 걸쳐 있는 가용성 영역에는 VM이 15개 이상 있어야 합니다.
Bronze 내구성의 가상 머신 확장 집합에 걸쳐 있는 확장하는 가용성 영역에는 6개 이상의 VM이 있어야 합니다.

Service Fabric 노드 형식에서 여러 영역에 대한 지원 사용

여러 가용성 영역을 지원하려면 Service Fabric 노드 유형을 사용하도록 설정해야 합니다.

첫 번째 값은 multipleAvailabilityZones이며 노드 형식에 대해 true로 설정해야 합니다.
두 번째 값은 sfZonalUpgradeMode이며 선택 사항입니다. 여러 가용성 영역 있는 노드 형식이 클러스터에 이미 있는 경우에는 이 속성을 수정할 수 없습니다. 이 속성은 UD에서 VM의 논리적 그룹화를 제어합니다.
- 이 값을 Parallel로 설정 하면 노드 형식의 VM이 UD로 그룹화되고 5개 UD에서 영역 정보를 무시합니다. 이렇게 설정 하면 모든 영역의 UD가 동시에 업그레이드됩니다. 이 배포 모드는 업그레이드 속도가 더 빠르지만 업데이트를 한 번에 한 영역에만 적용해야 한다는 SDP 지침에 위배되므로 권장되지 않습니다.
- 이 값을 생략 하거나 Hierarchical로 설정 하면 VM이 최대 15UD 영역 배포를 반영하도록 그룹화됩니다. 세 영역 각각에는 5개의 UD가 있습니다. 이렇게 하면 영역을 한 번에 하나씩 업데이트하고 첫 번째 영역 내에서 5개의 UD를 완료 한 후에만 다음 영역으로 이동합니다. 이 업데이트 프로세스는 클러스터와 사용자 애플리케이션에 더 안전합니다.
이 속성은 Service Fabric 애플리케이션 및 코드 업그레이드에 대한 업그레이드 동작만 정의합니다. 기본 가상 머신 확장 집합 업그레이드는 모든 가용성 영역에서 여전히 병렬 처리됩니다. 이 속성은 여러 영역을 사용하지 않는 노드 형식에 대한 UD 배포에 영향을 주지 않습니다.
세 번째 값은 vmssZonalUpgradeMode이며 선택 사항이며 언제든지 업데이트할 수 있습니다. 이 속성은 가상 머신 확장 집합이 가용성 영역에서 병렬로 또는 순차적으로 발생하도록 업그레이드 체계를 정의합니다.
- 이 값을 Parallel로 설정하면 모든 확장 집합 업데이트가 모든 영역에서 병렬로 발생합니다. 이 배포 모드는 업그레이드 속도가 더 빠르지만 업데이트를 한 번에 한 영역에만 적용해야 한다는 SDP 지침에 위배되므로 권장되지 않습니다.
- 이 값이 생략되거나 Hierarchical로 설정된 경우: 이렇게 하면 영역이 한 번에 하나씩 업데이트되고 첫 번째 영역 내에서 5개의 UD를 완료한 후에만 다음 영역으로 이동합니다. 이 업데이트 프로세스는 클러스터와 사용자 애플리케이션에 더 안전합니다.

Important

Service Fabric 클러스터 리소스 API 버전은 2020-12-01-preview 이상이어야 합니다.

클러스터 코드 버전은 8.1.321 이상이어야 합니다.

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

참고 항목

공용 IP 및 부하 분산 리소스는 문서의 앞부분에서 설명한 표준 SKU를 사용해야 합니다.
노드 형식의 multipleAvailabilityZones 속성은 노드 형식이 만들어지고 나중에 수정할 수 없는 경우에만 정의할 수 있습니다. 기존 노드 형식은 이 속성으로 구성할 수 없습니다.
sfZonalUpgradeMode을 생략 하거나 Hierarchical로 설정 하면 클러스터에 업그레이드 도메인이 더 있으므로 클러스터 및 애플리케이션 배포 속도가 느려집니다. 업그레이드 정책 시간 제한을 올바르게 조정하여 15개의 업그레이드 도메인에 필요한 업그레이드 시간을 고려하는 것이 중요합니다. 배포가 Azure Resource Service 배포 제한인 12시간을 초과하지 않도록 앱과 클러스터 모두에 대한 업그레이드 정책을 업데이트해야 합니다. 즉, 배포는 15개의 UD에 대해 12시간 이상 걸리지 않아야 합니다(즉, 각 UD에 대해 40분 이상 걸리지 않아야 합니다).
클러스터 안정성 수준을 Platinum로 설정하여 클러스터가 하나의 영역 중단 시나리오에서 유지되도록 합니다.
multipleAvailabilityZones를 사용하여 nodetype에 대한 DurabilityLevel 업그레이드는 지원되지 않습니다. 대신 내구성이 더 높은 새 노드 형식을 만듭니다.
SF는 3개의 AvailabilityZones만 지원합니다. 더 높은 숫자는 현재 지원되지 않습니다.

팁

sfZonalUpgradeMode을 Hierarchical로 설정하거나 생략하는 것이 좋습니다. 배포는 더 적은 양의 복제본 및 인스턴스에 영향을 주는 VM의 영역 배포를 따르므로 더 안전하게 만들 수 있습니다. 배포 속도가 우선 순위이거나 여러 가용성 영역에 있는 노드 유형에서 상태 비지정 워크로드만 실행되는 경우 Parallel로 설정된 sfZonalUpgradeMode을 사용합니다. 이로 인해 UD 워크가 모든 가용성 영역에서 병렬로 발생합니다.

여러 가용성 영역을 사용하여 노드 형식으로 마이그레이션

모든 마이그레이션 시나리오의 경우 여러 가용성 영역을 지원하는 새 노드 유형을 추가해야 합니다. 여러 영역을 지원하기 위해 기존 노드 유형을 마이그레이션할 수 없습니다. Service Fabric 클러스터 주 노드 유형 스케일 업 문서에는 새 노드 유형 및 새 노드 유형에 필요한 기타 리소스(예: IP 및 부하 분산 장치 리소스)를 추가하는 자세한 단계가 포함되어 있습니다. 또한 이 문서에서는 여러 가용성 영역 있는 새 노드 형식이 클러스터에 추가된 후 기존 노드 형식을 사용하지 않는 방법을 설명합니다.

기본 부하 분산 장치 및 IP 리소스를 사용하는 노드 유형에서 마이그레이션: 이 프로세스는 가용성 영역당 하나의 노드 유형이 있는 솔루션에 대한 아래의 하위 섹션에 설명되어 있습니다.

새 노드 형식의 경우, 유일한 차이점은 가용성 영역마다 하나씩이 아닌 모든 가용성 영역 대해 하나의 가상 머신 확장 집합과 하나의 노드 유형만 있다는 것입니다.
NSG를 사용하여 표준 SKU 부하 분산 장치 및 IP 리소스를 사용하는 노드 형식에서의 마이그레이션은 앞에서 설명한 것과 동일한 절차를 따릅니다. 그러나 새 부하 분산 장치, IP 및 NSG 리소스를 추가할 필요는 없습니다. 동일한 리소스를 새 노드 형식에서 재사용할 수 있습니다.

문제가 발생하면 지원팀에 문의하여 도움을 받으세요.

마이그레이션 옵션 2: 하나의 가상 머신 확장 집합을 각 영역에 고정하여 영역 배포

이 옵션을 사용해야 하는 경우

지금은 일반적으로 사용할 수 있는 구성입니다.

가용성 영역 Service Fabric 클러스터를 확장하려면 해당 지역에서 지원하는 각 가용성 영역에 주 노드 유형을 만들어야 합니다. 이렇게 하면 시드 노드가 각 주 노드 형식에 균등하게 분산됩니다.

주 노드 형식에 권장되는 토폴로지에는 아래에 설명된 리소스가 필요합니다.

주로 표시된 세 가지 노드 형식
- 각 노드 형식은 다른 영역에 있는 자체 가상 머신 확장 집합에 매핑되어야 합니다.
- 각 가상 머신 확장 집합에는 5개 이상의 노드(실버 내구성)가 있어야 합니다.

기존 표준 SKU 부하 분산 장치 및 IP 리소스를 사용하여 Service Fabric 비관리형 클러스터를 마이그레이션하는 방법

가상 머신 확장 집합에서 영역 사용

영역을 사용하도록 설정하려면 가상 머신 확장 집합에서 가상 머신 확장 집합 리소스에 다음 세 가지 값을 포함해야 합니다.

첫 번째 값은 가상 머신 확장 집합을 배포할 가용성 영역을 지정하는 zones 속성입니다.
두 번째 값은 true로 설정해야 하는 singlePlacementGroup 속성입니다.
세 번째 값은 Service Fabric 가상 머신 확장 집합 확장의 faultDomainOverride 속성입니다. 이 속성에는 이 가상 머신 확장 집합이 배치될 영역만 포함되어야 합니다. 예: "faultDomainOverride": "az1" Azure Service Fabric 클러스터는 지역 간 지원이 없기 때문에 모든 가상 머신 확장 집합 리소스는 동일한 지역에 배치되어야 합니다.

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

Service Fabric 클러스터 리소스에서 여러 주 노드 형식 사용

클러스터 리소스에서 하나 이상의 노드 형식을 주로 설정하려면 isPrimary 속성을 true로 설정합니다. 가용성 영역에서 Service Fabric 클러스터를 배포하는 경우 고유한 영역에 3개의 노드 형식이 있어야 합니다.

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

문제가 발생하면 지원팀에 문의하여 도움을 받으세요.

마이그레이션 옵션: 기본 SKU 부하 분산 장치 및 IP 리소스가 포함된 Service Fabric 비관리형 클러스터

이 옵션을 사용해야 하는 경우

마이그레이션하려는 기본 SKU 부하 분산 장치 및 IP 리소스가 포함된 기존 Service Fabric 비관리형 클러스터가 있는 경우 이 옵션을 사용해야 합니다. 기존 비관리형 클러스터에 표준 SKU 리소스가 있는 경우 위의 마이그레이션 옵션이 표시되어야 합니다. 비관리형 클러스터를 아직 만들지 않았지만 AZ를 사용하도록 설정하려는 경우 표준 SKU 리소스를 사용하여 만듭니다.

기본 SKU 부하 분산 장치 및 IP 리소스를 사용하여 Service Fabric 비관리형 클러스터를 마이그레이션하는 방법

기본 SKU와 함께 Load Balancer 및 IP를 사용하던 클러스터를 마이그레이션하려면 먼저 표준 SKU를 사용하여 완전히 새로운 부하 분산 장치 및 IP 리소스를 만들어야 합니다. 이러한 리소스는 업데이트할 수 없습니다.

새 부하 분산 장치 및 사용 하려는 새 교차 가용성 영역 노드 형식에서 IP를 참조합니다. 위의 예에서 세 개의 새로운 가상 머신 확장 집합 리소스가 영역 1, 2 및 3에 추가되었습니다. 이러한 Virtual Machine Scale Sets는 새로 생성된 부하 분상 장치 및 IP를 참조하고 Service Fabric 클러스터 리소스에서 주 노드 형식으로 표시됩니다.

시작하려면 기존 Azure Resource Manager 템플릿에 새 리소스를 추가합니다. 해당 리소스는 다음과 같습니다.
- 표준 SKU를 사용하는 공용 IP 리소스
- 표준 SKU를 사용하는 부하 분산 장치
- Virtual Machine Scale Sets를 배포하는 서브넷에서 참조하는 NSG
- 주로 표시된 세 가지 노드 형식
  - 각 노드 형식은 다른 영역에 있는 자체 가상 머신 확장 집합에 매핑되어야 합니다.
  - 각 가상 머신 확장 집합에는 5개 이상의 노드(실버 내구성)가 있어야 합니다.
이러한 리소스의 예는 샘플 템플릿에서 찾을 수 있습니다.
```
New-AzureRmResourceGroupDeployment `
    -ResourceGroupName $ResourceGroupName `
    -TemplateFile $Template `
    -TemplateParameterFile $Parameters
```

리소스 배포가 완료되면, 원래 클러스터에서 주 노드 유형의 노드를 사용하지 않도록 설정할 수 있습니다. 노드를 사용하지 않도록 설정하면 시스템 서비스는 이전에 배포한 새 주 노드 유형으로 마이그레이션됩니다.

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
}

노드를 모두 사용하지 않도록 설정하면 시스템 서비스는 영역에 분산되는 주 노드 형식에서 실행됩니다. 그런 다음 클러스터에서 사용하지 않도록 설정된 노드를 제거할 수 있습니다. 노드가 제거되면 원래 IP, 부하 분산 장치 및 가상 머신 확장 집합 리소스를 제거할 수 있습니다.

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

그런 다음 배포된 Resource Manager 템플릿에서 이러한 리소스에 대한 참조를 제거합니다.
마지막으로 DNS 이름 및 공용 IP를 업데이트합니다.

$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

문제가 발생하면 지원팀에 문의하여 도움을 받으세요.

다음을 통해 공유

Service Fabric 클러스터를 가용성 영역 지원으로 마이그레이션

필수 조건

Service Fabric 관리형 클러스터

Service Fabric 비관리형 클러스터

기존 표준 SKU 부하 분산 장치 및 IP 리소스

기본 SKU 부하 분산 장치 및 IP 리소스

가동 중지 시간 요구 사항

Service Fabric 관리형 클러스터

Service Fabric 비관리형 클러스터

Service Fabric 관리형 클러스터 마이그레이션

Service Fabric 비관리형 클러스터에 대한 마이그레이션 옵션

마이그레이션 옵션 1: 단일 가상 머신 확장 집합에서 여러 가용성 영역을 사용하도록 설정합니다.

이 옵션을 사용해야 하는 경우

기존 표준 SKU 부하 분산 장치 및 IP 리소스를 사용하여 Service Fabric 비관리형 클러스터를 마이그레이션하는 방법

Service Fabric 노드 형식에서 여러 영역에 대한 지원 사용

여러 가용성 영역을 사용하여 노드 형식으로 마이그레이션

마이그레이션 옵션 2: 하나의 가상 머신 확장 집합을 각 영역에 고정하여 영역 배포

이 옵션을 사용해야 하는 경우

기존 표준 SKU 부하 분산 장치 및 IP 리소스를 사용하여 Service Fabric 비관리형 클러스터를 마이그레이션하는 방법

가상 머신 확장 집합에서 영역 사용

Service Fabric 클러스터 리소스에서 여러 주 노드 형식 사용

마이그레이션 옵션: 기본 SKU 부하 분산 장치 및 IP 리소스가 포함된 Service Fabric 비관리형 클러스터

이 옵션을 사용해야 하는 경우

기본 SKU 부하 분산 장치 및 IP 리소스를 사용하여 Service Fabric 비관리형 클러스터를 마이그레이션하는 방법

다음 단계

피드백

추가 리소스