Windows Server 장애 조치 클러스터링 실행

GCP(Google Cloud Platform)에서 Windows Server를 이용해 장애 조치 클러스터를 만들 수 있습니다. 서버 그룹이 함께 작동하여 Windows 애플리케이션에 고가용성(HA)을 제공합니다. 클러스터 노드 하나가 실패하면 다른 노드가 소프트웨어를 이어서 실행합니다. 장애 조치가 자동으로 수행되도록 구성하거나(일반적인 구성) 수동으로 장애 조치를 트리거할 수도 있습니다.

이 가이드는 장애 조치 클러스터링, Active Directory(AD), Windows Server 관리에 익숙하신 분을 대상으로 합니다.

GCP의 네트워킹에 대한 간략한 개요는 GCP가 데이터 센터에 제공하는 장점: 네트워킹을 참조하세요.

아키텍처

이 가이드에서는 Compute Engine에서 예시 장애 조치 클러스터를 만드는 방법을 설명합니다. 예시 시스템에는 다음과 같은 세 개의 서버가 있습니다.

  • Windows Server 2016을 실행하는 기본 Compute Engine VM 인스턴스
  • 기본 인스턴스와 일치하도록 구성된 두 번째 인스턴스
  • AD 도메인 이름 서버(DNS). 이 서버는

    • Windows 도메인을 제공합니다.
    • 호스트 이름을 IP 주소로 확인합니다.
    • 클러스터에 필요한 쿼럼을 확보할 때 세 번째 '투표' 역할을 하는 파일 공유 감시를 포스팅합니다.

이 예시를 사용하려면 AD DNS만 만들면 됩니다. 프로덕션 시스템에서는 파일 공유 감시를 다른 곳에서 호스팅할 수 있으며 장애 조치 클러스터 지원을 위해 별도의 AD 시스템이 필요하지 않습니다. GCP에서의 AD 사용에 관한 자료 링크는 다음 과정을 참조하세요.

다음 다이어그램은 이 가이드에서 배포하는 아키텍처를 설명합니다.

장애 조치 클러스터의 두 Compute Engine VM을 보여주는 아키텍처 다이어그램

네트워크 라우팅 이해하기

클러스터를 장애 조치할 때 요청은 새 활성 노드로 이동해야 합니다. 클러스터링 기술은 일반적으로 IP 주소를 MAC 주소와 연결하는 주소 확인 프로토콜(ARP)을 이용해 라우팅을 처리합니다. GCP에서 가상 사설 클라우드(VPC) 시스템은 MAC 주소를 제공하지 않는 소프트웨어 정의 네트워킹을 사용합니다. 따라서 ARP가 브로드캐스트하는 변경사항은 라우팅에 영향을 주지 않습니다. 라우팅이 작동하게 하려면 클러스터는 내부 부하 분산기의 소프트웨어 수준 도움을 받아야 합니다.

일반적으로 내부 부하 분산은 들어오는 네트워크 트래픽을 VPC 내부의 여러 백엔드 인스턴스로 분산해 부하를 공유합니다. 장애 조치 클러스터링의 경우에는 내부 부하 분산을 사용하여 모든 트래픽을 현재 활성 클러스터 노드인 한 인스턴스로 라우팅합니다. 내부 부하 분산은 다음과 같은 방법으로 올바른 노드를 감지합니다.

  • 각 VM 인스턴스는 Windows 장애 조치 클러스터링에 대한 지원을 제공하는 Compute Engine 에이전트 인스턴스를 실행합니다. 에이전트는 VM 인스턴스의 IP 주소를 계속 추적합니다.
  • 부하 분산기의 프런트엔드는 들어오는 트래픽의 IP 주소를 애플리케이션에 제공합니다.
  • 부하 분산기의 백엔드는 상태 확인을 제공합니다. 상태 확인 프로세스는 특정 포트를 통해 VM 인스턴스의 고정 IP 주소를 사용하여 각 클러스터 노드에서 주기적으로 에이전트를 핑합니다. 기본 포트는 59998입니다.
  • 상태 확인은 애플리케이션의 IP 주소를 요청의 페이로드로 포함합니다.
  • 에이전트는 요청의 IP 주소를 호스트 VM의 IP 주소 목록과 비교합니다. 일치하는 항목을 찾으면 에이전트는 값 1로 응답합니다. 찾지 못하면 0으로 응답합니다.
  • 부하 분산기는 상태 확인 결과 정상이라고 판정된 VM을 표시합니다. VM 하나만 작업 부하의 IP 주소를 가지므로 언제나 하나의 VM만 상태 확인을 통과하게 됩니다.

장애 조치 중 발생하는 일

클러스터에서 장애 조치가 발생하면 다음과 같은 변경 사항이 적용됩니다.

  • Windows 장애 조치 클러스터링은 활성 노드의 상태를 변경해 장애가 있음을 표시합니다.
  • 장애 조치 클러스터링은 쿼럼에 정의된 대로 장애가 발생한 노드의 클러스터 리소스와 역할 일체를 가장 좋은 노드로 옮깁니다. 이 작업에는 연결된 IP 주소 이전도 포함됩니다.
  • 장애 조치 클러스터링 ARP 패킷을 브로드캐스트해 하드웨어 기반 네트워크 라우터에 IP 주소 이전을 알립니다. 이 시나리오에서는 GCP 네트워킹이 이러한 패킷을 무시합니다.
  • 이전이 끝나면 장애가 발생한 노드의 VM에 있는 Compute Engine 에이전트가 상태 확인에 대한 응답을 1에서 0으로 변경합니다. VM이 요청에 지정된 IP 주소를 더 이상 호스팅하지 않기 때문입니다.
  • 새 활성 노드에 대한 VM의 Compute Engine 에이전트도 상태 확인에 대한 응답을 0에서 1로 변경합니다.
  • 내부 부하 분산기는 장애가 발생한 노드로의 트래픽 라우팅을 중지하고 새 활성 노드로 트래픽을 라우팅합니다.

종합

지금까지 몇 가지 기본 개념을 살펴봤습니다. 다음은 아키텍처 다이어그램에서 주목해야 하는 세부사항입니다.

  • wsfc-2라는 VM에 대한 Compute Engine 에이전트는 활성 클러스터 노드임을 나타내는 값 1로 상태 확인에 응답합니다. wsfc-1의 경우 응답은 0입니다.
  • 부하 분산기는 화살표가 표시하는 것처럼 요청을 wsfc-2로 라우팅합니다.
  • 부하 분산기와 wsfc-2의 IP 주소는 모두 10.0.0.9입니다. 부하 분산기의 경우 이 주소는 지정된 프런트엔드 IP 주소입니다. VM의 경우에는 애플리케이션의 IP 주소입니다. 장애 조치 클러스터는 현재 활성 노드에서 이 IP 주소를 설정합니다.
  • 장애 조치 클러스터와 wsfc-2의 IP 주소는 모두 10.0.0.8입니다. VM은 클러스터 리소스를 호스팅하기 때문에 이 IP 주소를 가집니다.

가이드 진행에 관한 조언

이 가이드는 수많은 단계로 구성되어 있습니다. Microsoft 문서 같은 외부 문서의 단계를 수행해야 할 수도 있습니다. 외부 문서의 단계 수행에 대한 구체적인 정보를 제공하는 이 문서의 참고사항을 꼭 확인하세요.

이 가이드는 Google Cloud Platform 콘솔의 Cloud Shell을 사용합니다. GCP 콘솔 사용자 인터페이스나 Cloud SDK로 장애 조치 클러스터링을 설정할 수도 있지만, 이 가이드는 사용자의 편의를 위해 Cloud Shell을 주로 사용합니다. 이 방법을 사용하면 가이드를 더 빨리 완료할 수 있습니다. 적절한 경우 일부 단계에서는 GCP 콘솔을 사용합니다.

Cloud Shell

단계를 진행하는 동안 Compute Engine 영구 디스크의 스냅샷을 만드는 것이 좋습니다. 문제 발생 시 스냅샷을 사용하면 처음부터 다시 시작하지 않아도 됩니다. 이 가이드는 스냅샷을 만들기에 적절한 시기를 알려드립니다.

작업이 예상대로 진행되지 않는다면 읽고 있는 섹션에 안내가 있을 것입니다. 그렇지 않다면 문제해결 섹션을 참조하세요.

목표

  • 네트워크를 만듭니다.
  • Compute Engine VM 2개에 Windows Server 2016을 설치합니다.
  • Windows Server의 세 번째 인스턴스에 Active Directory를 설치하고 구성합니다.
  • 쿼럼의 파일 공유 감시와 작업 부하의 역할을 포함하는 장애 조치 클러스터를 설정합니다.
  • 내부 부하 분산기를 설정합니다.
  • 장애 조치 작업을 테스트해 클러스터가 작동하는지 확인합니다.

비용

이 가이드는 Windows Server 라이선스를 포함하는 Compute Engine 이미지를 사용합니다. 따라서 VM을 계속 실행하면 이 가이드를 진행하는 데 소요되는 비용이 상당할 수 있습니다. 사용하지 않을 때는 되도록 VM을 중지하세요.

이 가이드를 완료하는 데 필요한 예상 비용은 가격 계산기를 참조하세요.

시작하기 전에

  1. Google 계정에 로그인합니다.

    아직 계정이 없으면 새 계정을 등록하세요.

  2. Google Cloud Platform 프로젝트를 선택하거나 만듭니다.

    리소스 관리 페이지로 이동

  3. Google Cloud Platform 프로젝트에 결제가 사용 설정되어 있는지 확인하세요.

    결제 사용 설정 방법 알아보기

  4. Compute Engine API를 사용 설정합니다.

    API 사용 설정

  5. Cloud Shell의 인스턴스를 시작합니다.
    Cloud Shell 열기

네트워크 만들기

클러스터에 커스텀 네트워크가 필요합니다. VPC로 Cloud Shell에서 gcloud 명령어를 실행해 커스텀 네트워크와 하위 네트워크 한 개를 만드세요.

  1. 네트워크를 만듭니다.

    gcloud compute networks create wsfcnet --subnet-mode custom
    

    생성한 네트워크의 이름은 wsfcnet입니다.

  2. 하위 네트워크를 만듭니다. [YOUR_REGION]을 가까운 GCP 지역으로 바꿉니다.

    gcloud compute networks subnets create wsfcnetsub1 --network wsfcnet --region [YOUR_REGION] --range 10.0.0.0/16`
    

    생성한 하위 네트워크의 이름은 wsfcnetsub1입니다.

이 하위 네트워크의 IP 주소에 대한 CIDR 범위는 10.0.0.0/16입니다. 이것은 이 가이드에서 사용하는 예시 범위입니다. 프로덕션 시스템에서는 네트워크 관리자와 협력하여 시스템의 IP 주소에 적절한 범위를 할당하세요.

방화벽 규칙 만들기

기본적으로 네트워크는 외부 트래픽을 차단합니다. 서버의 원격 연결을 사용하려면 방화벽에서 포트를 열어야 합니다. Cloud Shell에서 gcloud 명령어를 사용해 규칙을 만드세요.

  1. 이 가이드에서는 주 네트워크에서 포트 22와 3389를 열어 SSH 및 RDP 연결을 사용 설정합니다. 다음 명령어에서 [YOUR_IPv4_ADDRESS]를 VM 인스턴스 연결에 사용하는 컴퓨터의 IP 주소로 바꿉니다. 프로덕션 시스템에서는 IP 주소 범위 또는 일련의 주소를 제공할 수 있습니다.

    gcloud compute firewall-rules create allow-ssh --network wsfcnet --allow tcp:22,tcp:3389 --source-ranges [YOUR_IPv4_ADDRESS]`
    
  2. 하위 네트워크에서 모든 포트의 모든 프로토콜을 허용해 서버가 서로 통신할 수 있게 합니다. 프로덕션 시스템에서는 필요에 따라 특정 포트만 여는 방법도 고려해 보세요.

    gcloud compute firewall-rules create allow-all-subnet --network wsfcnet --allow all --source-ranges 10.0.0.0/16`
    

    source-ranges 값은 하위 네트워크를 만들 때 사용한 CIDR 범위와 일치합니다.

  3. 방화벽 규칙을 확인합니다.

    gcloud compute firewall-rules list
    

    다음과 비슷한 출력이 표시됩니다.

    NAME              NETWORK  DIRECTION  PRIORITY  ALLOW            DENY
    allow-all-subnet  wsfcnet  INGRESS    1000      all
    allow-ssh         wsfcnet  INGRESS    1000      tcp:22,tcp:3389

Compute Engine에서 장애 조치 클러스터링 사용 설정

커스텀 메타데이터를 추가해 Compute Engine 에이전트에서 장애 조치 클러스터링을 사용하세요. 쉽게 설명하기 위해 이 가이드에서는 이러한 속성을 프로젝트의 모든 VM에 적용하는 프로젝트 수준 메타데이터를 사용합니다. 각 VM에 개별 메타데이터를 추가하거나 구성 파일을 생성하는 등의 다른 선택지는 Compute Engine 문서에서 설명합니다. 이 가이드는 wsfc-addrswsfc-agent-port의 기본 동작을 사용합니다. 이 값은 설정하지 않아도 됩니다.

gcloud compute project-info add-metadata --metadata enable-wsfc=true

서버 만들기

다음 단계에서는 서버 3개를 만듭니다. Cloud Shell에서 gcloud 명령어를 사용하세요.

첫 번째 클러스터 노드 서버 만들기

새 Compute Engine 인스턴스를 만드세요. 인스턴스는 다음과 같이 구성합니다.

  • 인스턴스 이름을 wsfc-1로 설정합니다.
  • --zone 플래그를 가까운 영역으로 설정합니다. [YOUR_ZONE]us-central1-a처럼 근처에 있는 편리한 영역으로 바꿉니다.
  • --machine-type 플래그를 n1-standard-2.로 설정합니다.
  • --image-project 플래그를 windows-cloud로 설정합니다.
  • --image-family 플래그를 windows-2016으로 설정합니다.
  • --scopes 플래그를 https://www.googleapis.com/auth/compute로 설정합니다.
  • --can-ip-forward 플래그를 설정해 IP 전달을 사용 설정합니다.
  • --private-network-ip 플래그를 10.0.0.4로 설정합니다.
  • 네트워크를 wsfcnet으로 설정하고 하위 네트워크를 wsfcnetsub1로 설정합니다.

[YOUR_ZONE]을 사용자 영역 이름으로 바꿔 다음 명령어를 실행합니다.

gcloud compute instances create wsfc-1 --zone [YOUR_ZONE] --machine-type n1-standard-2 --image-project windows-cloud --image-family windows-2016 --scopes https://www.googleapis.com/auth/compute --can-ip-forward --private-network-ip 10.0.0.4 --network wsfcnet --subnet wsfcnetsub1

두 번째 클러스터 노드 서버 만들기

두 번째 서버에서도 같은 단계를 반복하되 다음 예외를 적용하세요.

  • 인스턴스 이름을 wsfc-2로 설정합니다.
  • --private-network-ip 플래그를 10.0.0.5로 설정합니다.

[YOUR_ZONE]을 사용자 영역 이름으로 바꿉니다.

gcloud compute instances create wsfc-2 --zone [YOUR_ZONE] --machine-type n1-standard-2 --image-project windows-cloud --image-family windows-2016 --scopes https://www.googleapis.com/auth/compute --can-ip-forward --private-network-ip 10.0.0.5 --network wsfcnet --subnet wsfcnetsub1

Active Directory용 세 번째 서버 만들기

도메인 컨트롤러의 경우에는 동일한 단계를 수행하되 다음 예외를 적용하세요.

  • 인스턴스 이름을 wsfc-dc로 설정합니다.
  • --private-network-ip 플래그를 10.0.0.6으로 설정합니다.

[YOUR_ZONE]을 사용자 영역 이름으로 바꿉니다.

gcloud compute instances create wsfc-dc --zone [YOUR_ZONE] --machine-type n1-standard-2 --image-project windows-cloud --image-family windows-2016 --scopes https://www.googleapis.com/auth/compute --can-ip-forward --private-network-ip 10.0.0.6 --network wsfcnet --subnet wsfcnetsub1

인스턴스 보기

생성한 인스턴스의 세부정보를 확인할 수 있습니다.

gcloud compute instances list

다음과 비슷한 출력이 표시됩니다.

NAME     ZONE        MACHINE_TYPE      PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP     STATUS
wsfc-1   us-central1-a  n1-standard-2               10.0.0.4     35.203.131.133  RUNNING
wsfc-2   us-central1-a  n1-standard-2               10.0.0.5     35.203.130.194  RUNNING
wsfc-dc  us-central1-a  n1-standard-2               10.0.0.6     35.197.27.2     RUNNING

Compute Engine 인스턴스 그룹 만들기

클러스터 노드를 포함하도록 인스턴스 그룹을 만들면 필요한 내부 부하 분산기를 만들 수 있습니다. 부하 분산기는 다음 섹션에서 만듭니다. 도메인 컨트롤러 wsfc-dc는 인스턴스 그룹에 추가하지 마세요.

[YOUR_ZONE]을 사용자 영역 이름으로 바꿉니다.

gcloud compute instance-groups unmanaged create wsfc-group --zone=[YOUR_ZONE]
gcloud compute instance-groups unmanaged add-instances wsfc-group --instances wsfc-1,wsfc-2 --zone [YOUR_ZONE]

RDP를 통한 연결

Compute Engine 문서에서 RDP를 사용하여 Windows VM 인스턴스에 연결하는 방법을 확인할 수 있습니다. 다음 방법 중 하나를 이용하세요.

  • 기존 클라이언트를 사용합니다.
  • 브라우저에 Chrome RDP 플러그인을 추가하고 GCP Console로 연결합니다.

    RDP 사용 방법 알아보기

이 가이드에서 Windows 인스턴스에 연결하라고 할 때마다 선호하는 RDP 연결을 사용하세요.

Windows 네트워킹 구성

GCP 게이트웨이의 IP 주소를 가져오세요. Cloud Shell에서 [YOUR_REGION]을 사용자 지역 이름으로 바꿔 다음을 실행하세요.

gcloud compute networks subnets describe wsfcnetsub1 --region [YOUR_REGION]

다음과 같은 게이트웨이용 IP 주소가 출력에 포함됩니다.

gatewayAddress: 10.0.0.1

이제 RDP를 사용해 wsfc-1, wsfc-2, wsfc-dc에 연결하고 인스턴스별로 다음 단계를 반복하세요.

  1. 서버 관리자의 왼쪽 창에서 로컬 서버를 선택합니다.
  2. 이더넷속성 창에서 DHCP에서 할당을 클릭합니다.
  3. 이더넷을 오른쪽 버튼으로 클릭하고 속성을 선택합니다.
  4. 인터넷 프로토콜 버전 4(TCP/IPv4)를 더블클릭합니다.
  5. 다음 IP 주소 사용을 선택합니다.
  6. VM을 만들 때 VM에 할당한 IP 주소를 입력합니다.

    • wsfc-1에는 '10.0.0.4'를 입력하세요.
    • wsfc-2에는 '10.0.0.5'를 입력하세요.
    • wsfc-dc에는 '10.0.0.6'을 입력하세요.
  7. 서브넷 마스크에 '255.255.0.0'을 입력합니다.

  8. 기본 게이트웨이wsfcnetsub1용 게이트웨이의 IP 주소를 입력합니다. 이 섹션 시작 부분에서 이 IP 주소를 찾을 수 있습니다.

  9. wsfc-1wsfc-2에서는 다음 DNS 서버 주소 사용을 클릭합니다. wsfc-dc는 도메인 컨트롤러이므로 해당 VM의 기본 게이트웨이는 비워둡니다.

  10. 기본 설정 DNS 서버에 '10.0.0.6'을 입력합니다.

  11. 모든 대화상자를 닫습니다.

    이 변경사항은 VM 인스턴스의 가상 네트워크 어댑터를 재설정하기 때문에 RDP 연결이 끊어집니다.

  12. RDP 세션을 닫고 인스턴스에 다시 연결합니다. 이전 단계의 대화상자가 아직 열려 있다면 닫습니다.

  13. 로컬 서버의 속성 섹션에서 이더넷 설정에 로컬 서버의 IP 주소(10.0.0.4, 10.0.0.5 또는 10.0.0.6)가 반영되었는지 확인합니다. 반영되지 않았다면 인터넷 프로토콜 버전 4(TCP/IPv4) 대화상자를 다시 열고 설정을 업데이트합니다.

이제 wsfc-1wsfc-2의 스냅샷을 만들면 됩니다.

Active Directory 설정

이제 도메인 컨트롤러를 설정하세요.

  1. RDP를 사용해 wsfc-dc라는 서버에 연결합니다.
  2. 로컬 관리자 계정의 비밀번호를 설정합니다.
  3. 로컬 관리자 계정을 사용 설정합니다.
  4. 아래의 Microsoft 안내에 나온 단계와 이 추가 참고사항을 따라 도메인 컨트롤러를 설정합니다. 대부분의 설정에는 기본값을 사용하면 됩니다.

    • DNS 서버 역할 체크박스를 선택합니다. 이 단계는 안내에서 따로 설명하지 않습니다.
    • 필요한 경우 자동으로 대상 서버 다시 시작 체크박스를 선택합니다.
    • 파일 서버를 도메인 컨트롤러로 승격합니다.
    • 새 포리스트 추가 단계에서 도메인 이름을 'WSFC.TEST'로 지정합니다.
    • NetBIOS 도메인 이름을 'WSFC'(기본값)로 설정합니다.

    Microsoft 안내

이제 wsfc-dc의 스냅샷을 만들면 됩니다.

도메인 사용자 계정 만들기

wsfc-dc를 재시작하는 데 시간이 조금 걸릴 수 있습니다. 서버를 도메인에 조인하기 전에 RDP로 wsfc-dc에 로그인해 도메인 컨트롤러가 실행 중인지 확인하세요.

클러스터 서버 관리자 권한이 있는 도메인 사용자가 필요합니다. 방법은 다음과 같습니다.

  1. 도메인 컨트롤러(wsfc-dc)에서 시작을 클릭하고 dsa를 입력해 Active Directory 사용자 및 컴퓨터 앱을 찾아 엽니다.
  2. WSFC.TEST를 오른쪽 버튼으로 클릭하고 신규를 가리킨 다음 사용자를 클릭합니다.
  3. 전체 이름사용자 로그온 이름에 'clusteruser'를 입력합니다.
  4. 다음을 클릭합니다.
  5. 사용자 비밀번호를 입력하고 확인합니다. 대화상자에서 비밀번호 옵션을 선택합니다. 예를 들어 비밀번호가 만료되지 않도록 설정할 수도 있습니다.
  6. 설정을 확인하고 완료를 클릭합니다.
  7. clusteruserwsfc-dc의 관리자로 지정합니다.

    • wsfc-dc에서 Active Directory 사용자 및 컴퓨터 앱으로 이동합니다.
    • clusteruser를 오른쪽 버튼으로 클릭하고 그룹에 추가를 클릭한 다음 관리자를 입력하고 확인을 클릭합니다.

이 가이드는 필요할 때 WSFC.TEST\clusteruser 계정을 관리자 계정으로 사용합니다. 프로덕션 시스템에서는 계정 및 권한 할당에 관한 일반적인 보안 관행을 따르세요. 자세한 내용은 장애 조치 클러스터에 필요한 Active Directory 계정 개요를 참조하세요.

서버를 도메인에 조인

클러스터 노드 서버 2개를 WSFC.TEST 도메인에 추가합니다. 각 클러스터 노드 서버(wsfc-1wsfc-2)에서 다음 단계를 수행하세요.

  1. 서버 관리자 > 로컬 서버속성 창에서 작업 그룹을 클릭합니다.
  2. 변경을 클릭합니다.
  3. 도메인을 선택하고 'WSFC.TEST'를 입력합니다.
  4. 확인을 클릭합니다.
  5. WSFC.TEST\clusteruser의 사용자 인증 정보를 입력해 도메인을 조인합니다.
  6. 확인을 클릭합니다.
  7. 대화상자를 닫고 표시되는 메시지에 따라 서버를 다시 시작합니다.
  8. clusteruserwsfc-1wsfc-2의 관리자로 지정합니다.

    • 컴퓨터 관리 > 로컬 사용자 및 그룹 > 그룹 > 관리자를 더블클릭하고 추가를 클릭합니다.
    • 'clusteruser'를 입력하고 이름 확인을 클릭합니다.
    • 확인을 클릭합니다.

이제 세 VM의 스냅샷을 만들면 됩니다.

장애 조치 클러스터링 설정

장애 조치 클러스터 생성 및 구성 방법:

  1. RDP로 wsfc-1wsfc-2에 연결합니다.
  2. 아래의 Microsoft 안내에 나온 단계와 이 추가 참고사항을 따릅니다.

    • wsfc-1wsfc-2에 장애 조치 클러스터링 기능을 설치합니다. wsfc-dc에는 장애 조치 클러스터링 기능을 설치하지 마세요.
    • 도메인 사용자 WSFC.TEST\clusteruser로 장애 조치 클러스터 관리자 앱을 실행합니다. 그렇지 않으면 권한 문제가 발생할 수 있습니다. 필요한 권한을 가지려면 항상 이 방식으로 장애 조치 클러스터 관리자를 실행하거나 clusteruser로 서버에 연결해야 합니다.
    • wsfc-1wsfc-2를 클러스터에 노드로 추가합니다.
    • 구성 유효성 검사 시:

      • 테스트 옵션 페이지에서 선택한 테스트만 실행을 선택하고 다음을 클릭합니다.
      • 테스트 선택 페이지에서 저장소를 지워야 합니다. (별도의 독립형 물리적 서버에서처럼) Compute Engine에서 실행하면 저장소 옵션이 실패하기 때문입니다.

        클러스터 유효성 검사 중에 발생하는 일반적인 문제는 다음과 같습니다.

        • 복제본 간의 네트워크 인터페이스가 하나뿐입니다. 클라우드 기반 설치에는 적용되지 않으므로 이 문제는 무시해도 됩니다.
        • Windows 업데이트가 두 복제본에서 동일하지 않습니다. 업데이트를 자동으로 적용하도록 Windows 인스턴스를 구성했다면 한 노드가 다운로드하지 못한 업데이트를 다른 노드는 이미 적용했을 수도 있습니다. 모든 서버는 구성이 동일해야 합니다.
        • 재부팅이 대기 중입니다. 서버 변경사항은 재부팅해야 적용됩니다. 이 문제는 무시해선 안 됩니다.
        • 서버의 도메인 역할이 동일하지 않습니다. 이 문제는 무시해도 됩니다.
        • 모든 서버가 동일한 조직 단위(OU)에 있지 않습니다. 이 가이드는 OU를 전혀 사용하지 않지만 프로덕션 시스템에서는 클러스터를 자체 OU에 넣는 것이 좋습니다. 이 권장사항은 Microsoft 안내에서 설명합니다.
        • 서명되지 않은 드라이버가 발견되었습니다. 이 문제는 무시해도 됩니다.
    • 요약 페이지에서 마법사를 닫고 다시 여는 대신 검증된 노드를 사용하여 지금 클러스터 만들기를 선택해 클러스터를 계속 생성할 수 있습니다.

    • 클러스터 만들기 마법사의 액세스 포인트 페이지에서 클러스터의 이름을 'testcluster'로 지정합니다.

    • 주소 필드에 '10.0.0.8'을 입력합니다.

    MICROSOFT 안내

클러스터 관리자 추가

도메인 계정을 클러스터의 관리자로 추가하면 Windows PowerShell 같은 도구에서 클러스터 관련 작업을 수행할 수 있습니다. clusteruser 도메인 계정을 클러스터 관리자로 추가하세요.

  1. 클러스터 리소스를 호스팅하는 클러스터 노드의 장애 조치 클러스터 관리자에서, 왼쪽 창에서는 클러스터를 선택하고 오른쪽 창에서는 속성을 클릭합니다.
  2. 클러스터 사용 권한 탭을 선택합니다.
  3. 추가를 클릭하고 clusteruser를 추가합니다.
  4. 그룹 또는 사용자 이름 목록에서 clusteruser를 선택한 상태에서 권한 창의 전체 제어를 선택합니다.
  5. 적용확인을 클릭합니다.

이제 스냅샷을 만들면 됩니다.

파일 공유 감시 만들기

노드가 2개인 장애 조치 클러스터가 있지만 클러스터는 투표 메커니즘을 이용해 활성화할 노드를 결정합니다. 쿼럼 확보를 위해 파일 공유 감시를 추가할 수 있습니다.

이 가이드는 공유 폴더만 도메인 컨트롤러 서버에 추가합니다. 클러스터 노드 중 하나가 재시작할 때 서버가 오프라인이 되면 나머지 서버는 자체적으로 투표할 수 없기 때문에 전체 클러스터가 중단되기도 합니다. 이 가이드에서는 실시간 이전이나 자동으로 다시 시작 같은 GCP 인프라 기능이 공유 폴더를 유지할 수 있을 정도의 안정성을 제공한다고 가정합니다.

한층 더 가용성이 높은 파일 공유 감시를 만들고 싶다면 다음과 같은 방법이 있습니다.

  • Storage Spaces Direct를 사용하여 Windows Server의 클러스터로 공유를 제공하세요. 이 Windows Server 2016 기능은 쿼럼 감시에 높은 가용성을 제공할 수 있습니다. 예를 들어 Active Directory 도메인 컨트롤러용 클러스터를 만들면 가용성이 뛰어난 도메인 서비스와 파일 공유 감시를 동시에 제공할 수 있습니다.
  • Avere vFXT 같은 파일 서버 솔루션을 사용하세요.

다음 단계에 따라 감시를 위한 파일 공유를 만드세요.

  1. wsfc-dc에 연결합니다. 이 서버는 파일 공유를 호스팅합니다.
  2. 탐색기에서 C 드라이브를 찾습니다.
  3. 제목 표시줄에서 새 폴더 버튼을 클릭합니다.
  4. 새 폴더의 이름을 'shares'로 지정합니다.
  5. shares 폴더를 더블클릭해 폴더를 엽니다.
  6. 새 폴더를 추가하고 이름을 'clusterwitness-testcluster'로 지정합니다.

파일 공유 감시를 위한 공유 구성

클러스터가 사용할 수 있도록 파일 공유 감시 폴더에 대한 권한을 설정해야 합니다.

  1. 탐색기에서 clusterwitness-testcluster 폴더를 오른쪽 버튼으로 클릭하고 속성을 선택합니다.
  2. 공유 탭에서 고급 공유를 클릭합니다.
  3. 이 폴더 공유를 선택합니다.
  4. 권한을 클릭한 다음 추가를 클릭합니다.
  5. 개체 유형에서 컴퓨터를 선택하고 확인을 클릭합니다.
  6. 머신 계정 testcluster$를 추가합니다.
  7. testcluster$전체 제어 권한을 부여합니다.
  8. 적용을 클릭하고 대화상자를 모두 닫습니다.

장애 조치 클러스터에 파일 공유 감시 추가

이제 파일 공유 감시를 쿼럼 투표로 사용하도록 장애 조치 클러스터를 구성하세요.

  1. 클러스터 리소스(wsfc-1)를 호스팅하는 컴퓨터에서 장애 조치 클러스터 관리자를 엽니다.
  2. 왼쪽 창에서 클러스터 이름(testclusterWSFC.TEST)을 오른쪽 버튼으로 클릭하고 추가 작업을 가리킨 다음 클러스터 쿼럼 설정 구성을 클릭합니다.
  3. 각 단계에서 다음 버튼을 사용하여 마법사 페이지를 단계별로 진행합니다.
  4. 쿼럼 구성 옵션에는 Select the quorum witness(쿼럼 감시 선택)를 선택합니다.
  5. 파일 공유 감시 구성을 선택합니다.
  6. 파일 공유 경로에 '\10.0.0.6\clusterwitness-testcluster' 같은 공유 폴더 경로를 입력합니다. 이번 예시에서 10.0.0.6은 wsfc-dc VM의 IP 주소입니다.
  7. 설정을 확인하고 완료를 클릭합니다.

장애 조치 클러스터 테스트

이제 Windows Server 장애 조치 클러스터가 작동할 것입니다. 인스턴스 간의 클러스터 리소스 이동을 수동으로 테스트할 수 있습니다. 아직 작업이 완료되진 않았지만 이 시점에서 지금까지 수행한 모든 작업이 정상적으로 작동하는지 확인해 보세요.

  1. wsfc-1의 장애 조치 클러스터 관리자에서 현재 호스트 서버 이름을 확인합니다.
  2. Windows PowerShell을 clusteruser로 실행합니다.
  3. PowerShell에서 다음 명령어를 실행해 현재 호스트 서버를 변경합니다.

    Move-ClusterGroup -Name "Cluster Group"
    

현재 호스트 서버의 이름이 다른 VM으로 변경되어야 합니다.

문제가 해결되지 않으면 이전 단계를 검토하여 놓친 부분이 있는지 확인하세요. 가장 흔한 문제는 네트워크 액세스를 차단하는 방화벽 규칙이 없는 것입니다. 다른 문제를 확인하고 싶다면 문제해결 섹션을 참조하세요.

클러스터의 현재 호스트 서버로 네트워크 트래픽을 라우팅하는 데 필요한 내부 부하 분산기 설정으로 이동할 수도 있습니다.

이제 스냅샷을 만들면 됩니다.

역할 추가

Windows 장애 조치 클러스터링에서 역할은 클러스터링된 작업 부하를 호스팅합니다. 역할을 이용해 애플리케이션이 사용하는 IP 주소를 클러스터에 지정할 수 있습니다. 이 가이드에서는 인터넷 정보 서비스(IIS) 웹 서버인 테스트 작업 부하의 역할을 추가합니다. 방법은 다음과 같습니다.

  1. 장애 조치 클러스터 관리자의 작업 창에서 역할 구성을 선택합니다.
  2. ** 역할 선택** 페이지에서 다른 서버를 선택합니다.
  3. 클라이언트 액세스 지점 페이지에서 이름을 'IIS'로 입력합니다.
  4. 주소를 '10.0.0.9'로 설정합니다.
  5. 저장소 선택리소스 종류 선택은 건너뜁니다.
  6. 설정을 확인하고 완료를 클릭합니다.

역할 설정을 보여주는 확인 대화상자

내부 부하 분산기 만들기

지금부터는 활성 클러스터 호스트 노드로 네트워크 트래픽을 라우팅하는 데 필요한 내부 부하 분산기를 만들고 구성합니다. 사용자 인터페이스를 통해 내부 부하 분산이 어떻게 구성되는지 쉽게 확인할 수 있는 GCP 콘솔을 사용하겠습니다.

  1. GCP 콘솔에서 부하 분산 페이지로 이동합니다.

    부하 분산 열기

  2. 부하 분산기 만들기를 클릭합니다.

  3. TCP 부하 분산 카드에서 구성 시작을 클릭합니다.

  4. VM 사이에서만 분산을 선택하고 계속을 클릭합니다.

  5. 이름에는 'wsfc-lb'를 입력합니다.

아직은 만들기를 클릭하지 마세요.

백엔드 구성

기억하시겠지만 GCP 내부 부하 분산기는 정기적인 상태 확인으로 활성 노드를 결정합니다. 상태 확인은 활성 클러스터 노드에서 실행 중인 Compute Engine 클러스터 호스트 에이전트를 핑합니다. 상태 확인 페이로드는 클러스터링된 역할로 표시되는 애플리케이션의 IP 주소입니다. 에이전트는 노드가 활성 상태이면 값 1로, 활성 상태가 아니라면 0으로 응답합니다.

  1. 백엔드 구성을 클릭합니다.
  2. 현재 지역을 선택합니다.
  3. wsfcnet네트워크로 선택합니다.
  4. wsfc-group인스턴스 그룹으로 선택합니다.
  5. 상태 확인을 만듭니다.

    • 이름에는 'wsfc-hc'를 입력합니다.
    • TCP의 기본 프로토콜 설정을 수락하고 클러스터 호스트 에이전트 응답 포트를 '59998'로 변경합니다.
    • 요청에는 '10.0.0.9'를 입력합니다.
    • 응답에는 '1'을 입력합니다.
    • ** 확인 간격*에는 '2'를 입력합니다.
    • 제한시간에는 '1'을 입력합니다.
    • 저장 후 계속을 클릭합니다.

프런트엔드 구성

프런트엔드 구성은 부하 분산기가 들어오는 요청을 처리하는 방법을 정의하는 전달 규칙을 만듭니다. 이 가이드에서는 쉽게 설명하기 위해 하위 네트워크의 VM 간에 요청을 전송해 시스템을 테스트합니다.

프로덕션 시스템에서는 시스템을 인터넷 트래픽 같은 외부 트래픽에 개방할 수도 있습니다. 이렇게 하려면 외부 트래픽을 수락하고 내부 네트워크로 전달하는 요새 호스트를 만들어야 합니다. 요새 호스트 사용 방법은 이 가이드에서 다루지 않습니다.

  1. 가운데 창에서 프런트엔드 구성을 클릭합니다.
  2. 이름에는 'wsfc-lb-fe'를 입력합니다.
  3. 하위 네트워크(wsfcnetsub1)를 선택합니다.
  4. IP에는 임시(커스텀)를 선택합니다.
  5. '10.0.0.9'를 입력합니다. 이것은 역할에 설정한 것과 같은 IP 주소입니다.
  6. 포트에는 '80'을 입력합니다.
  7. 완료를 클릭합니다.

검토 및 완료

  1. 내부 부하 분산기 설정 요약을 보려면 가운데 창에서 검토 및 완료를 클릭합니다. 요약은 오른쪽 창에 표시됩니다.
  2. 만들기를 클릭합니다. 부하 분산기를 만드는 데는 시간이 조금 걸립니다.

    내부 부하 분산 최종 설정을 보여주는 GCP 콘솔

상태 확인용 방화벽 규칙 만들기

상태 확인이 대상에 도달할 수 있도록 방화벽 규칙을 상태 확인 시스템에 추가해야 한다는 알림이 GCP 콘솔에 표시되었을 것입니다. 이 섹션에서는 방화벽 규칙을 설정합니다.

  1. GCP 콘솔의 Cloud Shell로 돌아갑니다.

    Cloud Shell 열기

  2. 다음 명령어를 실행해 방화벽 규칙을 만듭니다.

    gcloud compute firewall-rules create allow-health-check --network wsfcnet --source-ranges 130.211.0.0/22,35.191.0.0/16 --allow tcp:59998`
    

Windows 방화벽 열기

이제 각 클러스터 노드(wsfc-1wsfc-2)에서 Windows 방화벽 규칙을 만드세요. 최소한 IP 주소 130.211.0.0/2235.191.0.0/16의 포트 59998을 통한 모든 수신 TCP 연결을 허용해야 합니다.

부하 분산기 유효성 검사

내부 부하 분산기를 실행하면 상태를 검사해 정상적인 인스턴스를 찾을 수 있는지 확인한 다음 장애 조치를 다시 테스트할 수 있습니다.

  1. GCP 콘솔에서 부하 분산 페이지로 돌아갑니다.

    부하 분산 열기

  2. 부하 분산기의 이름(wsfc-lb)을 클릭합니다.

    요약의 백엔드 섹션에 인스턴스 그룹이 나열될 것입니다.

    정상 열에는 1 / 2가 표시됩니다.

    이것은 예상된 결과입니다. 두 클러스터 노드 중 항상 하나만 장애 조치 클러스터에서 활성화되므로 부하 분산기 상태 확인은 활성화된 노드에서만 작동합니다.

    정상 열에 적절한 결과가 표시되지 않더라도 다음 단계를 진행하세요. 부하 분산기가 IP 주소를 찾으려면 장애 조치 작업을 한 번 이상 수행해야 할 수도 있습니다.

  3. 장애 조치를 수행하려면 장애 조치 클러스터 관리자에서 IIS 역할을 오른쪽 버튼으로 클릭하고 이동 > 가장 적합한 노드를 클릭하세요. 이 작업은 역할을 소유자 노드 필드에 표시된 새 노드로 옮깁니다.

    장애 조치 클러스터 관리자에 표시되는 소유자 노드 필드

  4. 상태실행 중으로 표시될 때까지 기다립니다.

  5. 부하 분산 페이지로 돌아가 새로고침을 클릭한 다음 정상 열이 여전히 1 / 2로 표시되는지 확인합니다.

    2개 중에서 정상 인스턴스가 하나임을 보여주는 부하 분산기 상태

팁: gcloud 도구를 이용해 어느 인스턴스가 정상 상태인지 확인할 수 있습니다. 여기서 [REGION]은 사용자의 지역입니다.

gcloud compute backend-services get-health wsfc-lb --region=[REGION]

출력은 다음과 같이 표시됩니다.

backend: https://www.googleapis.com/compute/v1/projects/[PROJECT_NAME]/zones/us-west1-a/instanceGroups/wsfc-group
status:
  healthStatus:
  - healthState: UNHEALTHY
    instance: https://www.googleapis.com/compute/v1/projects/[PROJECT_NAME]/zones/us-west1-a/instances/wsfc-1
    ipAddress: 10.0.0.4
    port: 80
  - healthState: HEALTHY
    instance: https://www.googleapis.com/compute/v1/projects/[PROJECT_NAME]/zones/us-west1-a/instances/wsfc-2
    ipAddress: 10.0.0.5
    port: 80
  kind: compute#backendServiceGroupHealth

애플리케이션 설치

이제 클러스터가 있으므로 각 노드에서 애플리케이션을 설정하고 클러스터링된 환경에서 실행되도록 구성할 수 있습니다.

이 가이드에서는 클러스터가 내부 부하 분산기와 실제로 작업 중임을 보여주는 항목을 설정해야 합니다. 각 VM에 IIS를 설정해 간단한 웹페이지를 제공하세요.

클러스터의 HA용 IIS는 설정하지 않습니다. 각각 다른 웹페이지를 제공하는 별도의 IIS 인스턴스를 만들게 됩니다. 장애 조치가 끝나면 웹 서버는 공유 콘텐츠가 아닌 자체 콘텐츠를 제공합니다.

HA용 애플리케이션 또는 IIS 설정은 이 가이드에서 다루지 않습니다.

IIS 설정

  1. 각 클러스터 노드에 IIS를 설치합니다.

    • 일반 HTTP 기능기본 문서가 선택되어 있는지 확인합니다.
    • 확인 페이지에서 대상 서버를 자동으로 다시 시작하는 체크박스를 선택합니다.
  2. 각 웹 서버가 작동하는지 확인합니다.

    1. RDP로 wsfc-dc라는 VM에 연결합니다.
    2. 서버 관리자 상단의 속성 섹션에서 IE 보안 강화 구성을 사용 중지합니다.
    3. Internet Explorer를 엽니다.
    4. 각 서버의 IP 주소를 탐색합니다.

      http://10.0.0.4/
      http://10.0.0.5/
      

둘 다 기본 IIS 웹페이지인 환영 페이지가 표시됩니다.

기본 웹페이지 수정

현재 페이지를 제공하는 서버를 쉽게 확인할 수 있도록 각각의 기본 웹페이지를 변경하세요.

  1. RDP로 wsfc-1이라는 VM에 연결합니다.
  2. 관리자 권한으로 메모장을 실행합니다.
  3. 메모장에서 C:\inetpub\wwwroot\iistart.htm을 엽니다. 텍스트 파일이 아닌 모든 파일을 찾아야 합니다.
  4. <title> 요소에서 텍스트를 현재 서버의 이름으로 변경합니다. 예를 들면 다음과 같습니다.

        <title>wsfc-1</title>
    
  5. HTML 파일을 저장합니다.

  6. wsfc-2에도 같은 단계를 반복하되 <title> 요소를 wsfc-2로 설정합니다.

이제 이러한 서버 중 하나에서 제공하는 웹페이지를 보면 서버 이름이 Internet Explorer 탭의 제목으로 표시됩니다.

장애 조치 테스트

  1. RDP로 wsfc-dc라는 VM에 연결합니다.
  2. Internet Explorer를 엽니다.
  3. 부하 분산기 역할의 IP 주소를 탐색합니다.

    http://10.0.0.9/
    

    탭 제목에 현재 서버 이름이 표시되는 시작 페이지가 나타납니다.

  4. 실패 시뮬레이션을 위해 현재 서버를 중지합니다. Cloud Shell에서 다음 명령어를 실행해 [INSTANCE_NAME]을 이전 단계에서 확인한 현재 서버의 이름(예: wsfc-1)으로 교체하세요.

    gcloud compute instances stop [INSTANCE_NAME]
    
  5. RDP 연결을 wsfc-dc로 전환합니다.

    부하 분산기가 이동을 감지해 트래픽을 다시 라우팅하기까지 몇 분 정도 걸릴 수 있습니다.

  6. 30초 정도 지나면 Internet Explorer에서 페이지를 새로고침합니다.

    이제 탭 제목에 새 활성 노드 이름이 표시될 것입니다. 예를 들어 처음에는 wsfc-1이 활성화되었다면 지금은 제목에 wsfc-2가 표시됩니다. 변경사항이 바로 표시되지 않거나 '페이지를 찾을 수 없음' 오류가 표시되면 브라우저를 다시 새로고침하세요.

축하합니다! 이제 GCP에서 Windows Server 2016 장애 조치 클러스터가 실행됩니다.

문제해결

다음은 정상적으로 작동하지 않을 때 확인해야 할 일반적인 문제입니다.

GCP 방화벽 규칙에서 상태 확인 차단

상태 확인이 작동하지 않는다면 상태 확인 시스템이 사용하는 IP 주소인 130.211.0.0/2235.191.0.0/16에서 들어오는 트래픽을 허용하는 방화벽 규칙이 있는지 다시 확인하세요.

Windows 방화벽에서 상태 확인 차단

각 클러스터 노드의 Windows 방화벽에서 포트 59998이 열려 있는지 확인하세요.

DHCP를 사용하는 클러스터 노드

클러스터의 각 VM에는 반드시 고정 IP 주소가 있어야 합니다. VM이 Windows에서 DHCP를 사용하도록 구성되었다면 IPv4 주소가 GCP 콘솔에서 표시하는 VM의 IP 주소와 일치하도록 Windows 네트워킹 설정을 변경하세요. 또한 게이트웨이 IP 주소를 GCP VPC의 하위 네트워크 게이트웨이 주소와 일치하도록 설정해야 합니다.

방화벽 규칙의 GCP 네트워크 태그

방화벽 규칙에서 네트워크 태그를 사용한다면 모든 VM 인스턴스에 올바른 태그가 설정되어 있는지 확인하세요. 이 가이드에서는 태그를 사용하지 않지만 다른 이유로 태그를 설정했다면 일관되게 사용해야 합니다.

삭제

이 가이드에서 사용한 리소스 비용이 Google Cloud Platform 계정에 청구되지 않도록 하는 방법은 다음과 같습니다.

장애 조치 클러스터링 가이드를 완료한 후에는 이후에 요금이 청구되지 않도록 Google Cloud Platform에서 만든 리소스를 삭제하세요. 다음 섹션에서는 이러한 리소스를 삭제하거나 사용 중지하는 방법을 설명합니다.

프로젝트 삭제

비용이 청구되지 않도록 하는 가장 쉬운 방법은 가이드에서 만든 프로젝트를 삭제하는 것입니다.

프로젝트를 삭제하는 방법은 다음과 같습니다.

  1. GCP Console에서 프로젝트 페이지로 이동합니다.

    프로젝트 페이지로 이동

  2. 프로젝트 목록에서 삭제할 프로젝트를 선택하고 삭제를 클릭합니다.
  3. 대화상자에서 프로젝트 ID를 입력한 다음 종료를 클릭하여 프로젝트를 삭제합니다.

인스턴스 삭제

Compute Engine 인스턴스를 삭제하는 방법은 다음과 같습니다.

  1. GCP Console에서 VM 인스턴스 페이지로 이동합니다.

    VM 인스턴스 페이지로 이동

  2. 다음의 옆에 있는 체크박스를 클릭합니다. 삭제할 인스턴스
  3. 페이지 상단의 삭제 버튼을 클릭하여 인스턴스를 삭제합니다.

영구 디스크 삭제

영구 디스크를 삭제하는 방법:

  1. GCP 콘솔에서 디스크 페이지로 이동합니다.

    디스크 페이지로 이동

  2. 삭제할 디스크 옆의 체크박스를 선택합니다.

  3. 페이지 상단의 삭제 버튼을 클릭합니다.

다음 단계

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

Compute Engine 문서