Service Fabric 독립 실행형 클러스터 배포 계획 및 준비

클러스터를 만들기 전에 다음 단계를 수행합니다.

클러스터 인프라 계획

클러스터가 견뎌낼 수 있는 실패의 종류를 결정할 수 있도록 사용자가 “소유한” 컴퓨터에서 Service Fabric 클러스터를 만들려고 합니다. 예를 들어 이러한 컴퓨터를 제공하는 전원 줄 또는 인터넷 연결을 구분해야 하나요? 또한 이러한 컴퓨터의 물리적 보안을 고려합니다. 컴퓨터는 어디에 있으며 누가 액세스해야 하나요? 이러한 결정을 내리면 다양한 장애 도메인에 컴퓨터를 논리적으로 매핑할 수 있습니다(다음 단계 참조). 프로덕션 클러스터에 대한 인프라 계획은 테스트 클러스터보다 더 복잡합니다.

장애 도메인 및 업그레이드된 도메인의 수 확인

FD(장애 도메인)은 실패의 물리적 단위이며 데이터 센터의 물리적 인프라에 직접 연관됩니다. 장애 도메인은 실패한 단일 지점이 공유하는 하드웨어 구성 요소(컴퓨터, 스위치, 네트워크 등)로 구성됩니다. 쉽게 말해 장애 도메인과 랙 간에 1:1 매핑이 없지만 각 랙은 장애 도메인으로 간주될 수 있습니다.

FD를 ClusterConfig.json에 지정하는 경우 각 FD의 이름을 선택할 수 있습니다. 서비스 패브릭은 내부에서 인프라 토폴로지를 반영할 수 있도록 계층적 FD를 지원합니다. 예를 들어 다음 FD가 유효합니다.

• "faultDomain": "fd:/Room1/Rack1/Machine1"
• "faultDomain": "fd:/FD1"
• "faultDomain": "fd:/Room1/Rack1/PDU1/M1"

UD(업그레이드 도메인)는 노드의 논리적 단위입니다. Service Fabric이 업그레이드(애플리케이션 업그레이드 또는 클러스터 업그레이드)를 조정하는 동안 다른 UD의 노드를 요청을 처리하는 데 계속 사용할 수 있도록 업그레이드를 수행하기 위해 UD의 모든 노드를 사용합니다. 컴퓨터에 수행하는 펌웨어 업그레이드는 UD를 인식하지 못하므로 한 번에 하나의 컴퓨터를 수행해야 합니다.

이러한 개념에 대해 생각하는 가장 간단한 방법은 FD를 계획되지 않은 오류의 단위로, UD를 계획된 유지 관리의 단위로 인식하는 것입니다.

UD를 ClusterConfig.json에 지정하는 경우 각 UD의 이름을 선택할 수 있습니다. 예를 들어 다음 이름이 유효합니다.

• "upgradeDomain": "UD0"
• "upgradeDomain": "UD1A"
• "upgradeDomain": "DomainRed"
• "upgradeDomain": "Blue"

FD 및 UD에 대한 자세한 내용은 Service Fabric 클러스터 설명을 참조하세요.

컴퓨터 업데이트 및 교체를 담당하는 사례와 같이 노드의 유지 관리 및 관리에 대한 모든 권한이 있는 경우 프로덕션의 클러스터는 프로덕션 환경에서 지원되도록 하기 위해 3개 이상 FD를 포괄해야 합니다. 환경에서 실행 중인 클러스터의 경우(즉, Amazon Web Services VM 인스턴스) 컴퓨터에 대한 전체 제어 권한이 없으면 클러스터에 최소 5개의 FD가 있어야 합니다. 각 FD는 하나 이상의 노드를 가질 수 있습니다. 이는 타이밍에 따라 컴퓨터 업그레이드 및 업데이트가 클러스터의 애플리케이션 및 서비스 실행을 방해할 수 있는 문제를 방지하기 위한 것입니다.

초기 클러스터 크기 결정

일반적으로 클러스터의 노드 수는 클러스터에서 실행되는 서비스 및 컨테이너의 수, 워크로드를 유지하는 데 필요한 리소스의 양과 같은 비즈니스 요구 사항에 따라 결정됩니다. 프로덕션 클러스터의 경우 5개의 FD를 포괄하는 클러스터에 최소 5개 노드를 갖는 것이 좋습니다. 그러나 위에서 설명한 대로 해당 노드에 대한 모든 권한이 있고 세 FD를 포괄할 수 있는 경우 3개의 노드가 작업을 수행해야 합니다.

상태 저장 워크로드를 실행 중인 테스트 클러스터는 노드가 세 개인 반면, 상태 비저장 워크로드를 실행 중인 테스트 클러스터는 하나의 노드만 필요합니다. 개발 목적으로 지정된 컴퓨터에 노드를 하나 이상 가질 수 있다는 점을 유의해야 합니다. 단, 프로덕션 환경에서 Service Fabric은 실제 또는 가상 머신당 하나의 노드만 지원합니다.

노드의 역할을 하는 컴퓨터 준비

Service Fabric 클러스터의 머신에 권장되는 사양은 다음과 같습니다.

• 최소 16GB의 RAM
• 최소 40GB의 사용 가능한 디스크 공간
• 4 코어 이상의 CPU
• 모든 컴퓨터에 대해 보안 네트워크 또는 네트워크 연결성
• Windows Server OS 설치(유효한 버전: 2012 R2, 2016, 1709 또는 1803) Service Fabric 버전 6.4.654.9590 이상에서는 Server 2019 및 1809도 지원합니다.
• .NET Framework 4.5.1 이상, 전체 설치
• Windows PowerShell 3.0
• RemoteRegistry 서비스는 모든 컴퓨터에서 실행되어야 함
• Service Fabric 설치 드라이브는 NTFS 파일 시스템이어야 합니다.
• Windows 서비스 성능 로그와 경고 및 Windows 이벤트 로그를 사용하도록 설정해야 합니다.
• 원격 사용자 계정 컨트롤을 사용하지 않도록 설정해야 함

Windows Server용 Service Fabric 독립 실행형 패키지 다운로드

다운로드 링크 - Service Fabric 독립 실행형 패키지 -Windows Server, 클러스터의 일부가 아닌 배포 컴퓨터 또는 클러스터의 일부인 컴퓨터 중 하나에 패키지의 압축을 풉니다.

클러스터 구성 수정

독립 실행형 클러스터를 만들려면 클러스터의 사양을 설명하는 독립 실행형 클러스터 구성 ClusterConfig.json 파일을 만들어야 합니다. 아래 링크에서 찾을 수 있는 템플릿의 구성 파일을 기반으로 할 수 있습니다.
독립 실행형 클러스터 구성

이 파일의 섹션에 대한 자세한 내용은 독립 실행형 Windows 클러스터에 대한 구성 설정을 참조하세요.

다운로드한 패키지에서 ClusterConfig.json 파일 중 하나를 열고 다음 설정을 수정합니다.

클러스터 구성에서 모든 설정을 환경에 구성한 후 클러스터 환경에 대해 테스트할 수 있습니다(7단계).

환경 설정

클러스터 관리자가 Service Fabric 독립 실행형 클러스터를 구성할 때 환경은 다음 기준으로 설정되어야 합니다.

1. 클러스터를 만드는 사용자에는 클러스터 구성 파일에서 노드로 나열된 모든 컴퓨터에 대한 관리자 수준 보안 권한이 있어야 합니다.

2. 클러스터가 생성되는 컴퓨터 뿐 아니라 각 클러스터 노드 컴퓨터는 다음이 필수입니다.

   • Service Fabric SDK 제거
   • Service Fabric 런타임 제거
   • Windows 방화벽 서비스(mpssvc) 활성화
   • 원격 레지스트리 서비스(remoteregistry) 활성화
   • 파일 공유(SMB) 활성화
   • 클러스터 구성 포트에 따라 필요한 포트 열기
   • Windows SMB 및 원격 레지스트리 서비스: 135, 137, 138, 139 및 445에 대한 필요한 포트 열기
   • 네트워크 간 연결

3. 모든 클러스터 노드 컴퓨터는 도메인 컨트롤러여서는 안 됩니다.

4. 배포되는 클러스터가 보안 클러스터인 경우 필수 보안 구성 요소가 배치되고 구성에 대해 올바르게 구성되어 있는지 유효성을 검사합니다.

5. 클러스터 컴퓨터를 인터넷에서 액세스할 수 없는 경우 클러스터 구성에서 다음을 설정합니다.

   • 원격 분석 사용 안 함: ‘속성’에서 “enableTelemetry”: false 설정
   • 자동 패브릭 버전 다운로드 및 현재 클러스터 버전이 곧 지원 종료된다는 알림 사용 안 함: 속성에서 “fabricClusterAutoupgradeEnabled”: false 설정
   • 또는 네트워크 인터넷 액세스가 허용 목록 도메인으로 제한될 경우 자동 업그레이드를 위해 go.microsoft.com, download.microsoft.com 도메인이 필요합니다.

6. 적절한 Service Fabric 바이러스 백신 예외 설정:

TestConfiguration 스크립트를 사용하여 환경 유효성 검사

TestConfiguration.ps1 스크립트는 독립 실행형 패키지에서 찾을 수 있습니다. 위의 조건 중 일부의 유효성을 검사하는 모범 사례 분석기로 사용되며 지정된 환경에 클러스터를 배포할 수 있는지 여부를 확인하는 온전성 검사로 사용되어야 합니다. 오류가 있는 경우 문제 해결은 환경 설치 아래의 목록을 참조하세요.

이 스크립트는 클러스터 구성 파일에서 노드로 나열된 모든 컴퓨터에 대한 관리자 액세스 권한이 있는 모든 컴퓨터에서 실행될 수 있습니다. 이 스크립트가 실행되는 컴퓨터가 클러스터의 일부일 필요는 없습니다.

PS C:\temp\Microsoft.Azure.ServiceFabric.WindowsServer> .\TestConfiguration.ps1 -ClusterConfigFilePath .\ClusterConfig.Unsecure.DevCluster.json
Trace folder already exists. Traces will be written to existing trace folder: C:\temp\Microsoft.Azure.ServiceFabric.WindowsServer\DeploymentTraces
Running Best Practices Analyzer...
Best Practices Analyzer completed successfully.


LocalAdminPrivilege        : True
IsJsonValid                : True
IsCabValid                 : True
RequiredPortsOpen          : True
RemoteRegistryAvailable    : True
FirewallAvailable          : True
RpcCheckPassed             : True
NoConflictingInstallations : True
FabricInstallable          : True
Passed                     : True

현재 이 구성 테스트 모듈은 보안 구성을 확인하지 않으므로 독립적으로 수행되어야 합니다.

다음 단계

• Windows Server에서 실행되는 독립 실행형 클러스터 만들기