확장된 VMware vSAN 클러스터 만들기

모든 필요 조건 구성이 완료되면 이제 VMware vSAN 확장 클러스터 생성을 계속할 수 있습니다. 이 단계에서는 OCI Dedicated Region A 및 OCI Dedicated Region B의 호스트 간 접속과 세번째 영역에 배치된 Witness 노드 간의 접속을 공식화합니다.

빠른 시작 마법사를 사용하거나 VMware vCenter UI에서 Cluster, Configure, vSAN, Fault Domains and Stretched Cluster로 직접 이동할 수 있습니다.

이 프로세스 중에 다음을 구성합니다.

  • OCI Dedicated Region A 호스트를 결함 도메인 1에 지정합니다.
  • OCI Dedicated Region B 호스트를 결함 도메인 2에 지정합니다.
  • 쿼럼에 대해 Witness Host(이전에 추가됨) 지정

자세한 내용은 Stretched Cluster Requirements 및 VMware vSAN Stretched Cluster Guide를 참조하십시오.

확장된 클러스터가 생성된 후 다음을 수행합니다.

  • vSAN Health Checks를 실행하여 클러스터 무결성을 검증합니다.
  • 네트워킹 관련 오류(예: MTU 불일치 또는 경로 지정 문제)를 해결합니다.

주:

원래 클러스터의 특정 호스트에서 사용되지 않는 vSAN 객체가 발생할 수 있습니다. 이러한 객체를 제거하려면 이 설명서를 참조하십시오. vSAN 데이터 저장소에서 액세스할 수 없는 객체를 삭제하는 방법

완료되면 클러스터가 상위 90s에 vSAN 건전성 점수를 보고해야 합니다. 이는 확장된 구성이 성공했음을 나타냅니다.

NSX 구성

VMware vSAN 클러스터가 확장되면 교차 사이트 오버레이 네트워킹을 지원하도록 VMware NSX를 업데이트합니다. 이 단계를 수행하면 두 지역의 ESXi 호스트가 각 전송 영역을 사용하여 NSX 터널을 통해 통신할 수 있습니다.

NSX TEP 구성 복제
  • NSX TEP IP 풀을 OCI 전용 리전 B NSX 관리자에서 OCI 전용 리전 NSX 관리자로 복사합니다.
  • OCI Dedicated Region B에 있는 관리 ESXi 호스트와의 IP 충돌을 방지하려면 OCI Dedicated Region A에서 .10부터 시작하도록 새 IP 풀을 구성합니다.

    예: OCI Dedicated Region에서 NSX Manager에서 OCI Dedicated Region B 호스트에 대해 .10–.20 범위의 TEP 풀을 생성하여 기존 IP와 겹치지 않도록 합니다.

OCI Dedicated Region A에서 OCI Dedicated Region B 업링크 프로파일 생성
  • OCI Dedicated Region A NSX Manager에서 OCI Dedicated Region B 호스트를 위한 새로운 업링크 프로파일을 정의합니다.
  • 올바른 VLAN ID를 사용하고 업링크 순서가 OCI Dedicated Region B 구성과 일치하는지 확인합니다.
NSX용 호스트 준비
  • OVERLAY-TZ 및 VLAN-TZ를 전송 영역으로 사용합니다.
  • 호스트 준비 중 호스트가 OCI Dedicated Region A 또는 OCI Dedicated Region B에서 온 것인지 여부에 따라 적절한 Uplink Profile을 지정합니다.

    주: 일부 시나리오에서는 특히 페일오버 이벤트 후 NSX 터널 인터페이스가 제대로 작동하지 않을 수 있습니다. 이 문제를 해결하려면 다음을 수행합니다.

    • 영향을 받는 ESXi 호스트 또는 재부트
    • 호스트에서 SSH를 통해 services.sh 재시작을 실행합니다.

    이렇게 하면 모든 NSX 서비스가 올바른 순서로 시작되고 터널 안정성이 복원됩니다.

NSX 오버레이 세그먼트 생성
  • 네 개의 NSX 오버레이 세그먼트를 생성합니다.
  • 두 사이트의 모든 ESXi 호스트에서 이러한 세그먼트가 표시되고 동기화되는지 확인합니다.
DHCP 구성(선택사항)
  • 선택적으로 새 오버레이 세그먼트에 대해 DHCP 설정을 구성합니다.
  • DNS 설정은 이 설명서 앞부분에서 이미 구성되어 있으므로 여기서 반복할 필요가 없습니다.
엔드투엔드 오버레이 연결 검증
  • 4개의 VM을 배포하여 두 리전의 각 호스트에 하나씩 배치합니다.
  • 각 VM에 각 세그먼트 범위 내의 정적 IP 주소를 지정합니다.
  • 세그먼트 게이트웨이 및 VM 간 핑 - 확장된 환경에서 L3 오버레이 연결을 검증합니다.

오버레이 VM에 대해 외부 접속 사용

VMware NSX 오버레이 VM이 외부 네트워크에 액세스하도록 허용하려면 관련 VLAN에 대한 NAT 규칙 및 경로 지정을 구성합니다.

VCN-MGMT-Active 및 VCN-MGMT-Failover 모두에서 NSX Edge 업링크 1 VLAN에 대한 NAT 구성을 업데이트합니다.

  • 두 영역에서 동일한 외부 액세스 IP를 사용하여 OCI 전용 영역 A 배치 중 사용된 IP와 일치시킵니다.
  • 사용된 IP가 NSX Manager에 표시되는 NSX Edge 노드의 HA VIP인지 확인합니다.

또한 vSphere VLAN에 대한 외부 액세스 규칙을 업데이트합니다.

  • 두 VCN에서 vcenter-vip, nsxt-manager-vip 및 HCX-manager-vip(HCX가 사용되는 경우)에 대한 NAT 규칙을 구성합니다.

DNS 전달 지원

오버레이 VM은 일반적으로 NSX-T에 정의된 DNS 포워더(예: 192.168.253.253)를 사용합니다. 이러한 DNS 쿼리를 라우팅하려면 다음을 수행합니다.

  1. NAT 게이트웨이에 대한 전용 경로 테이블을 만듭니다.
  2. 정적 경로 정의:
    • 대상: 10.x.x.x(오버레이 VM 서브넷)
    • 대상: NAT 게이트웨이
    • DNS 전달자 IP: 192.168.253.253

이 구성은 두 사이트에서 모두 복제되어야 합니다. 일관된 동작을 위해 새 경로 테이블을 NAT 게이트웨이와 연관시킵니다.

ESXi 호스트 VLAN을 부동 VCN에 재지정

현재 설정에서 각 ESXi 호스트는 두 개의 물리적 NIC로 프로비전되며, 각각 VCN-Primary(OCI Dedicated Region A) 및 VCN-Secondary(OCI Dedicated Region B)에 대한 VNIC 연결을 통해 구성된 기본 VLAN 집합과 연관됩니다. 이러한 VNIC는 해당 VCN에 연결된 보조 CIDR 블록(172.45.0.0/16)을 사용하여 구성됩니다.

확장된 구성으로의 전환을 완료하려면 태그가 200 이상인 모든 VLAN(예: vSphere, HCX, NSX Edge 등)을 부동 VCN으로 마이그레이션해야 합니다.
  • OCI 전용 리전의 VCN-MGMT-Active
  • OCI Dedicated Region B의 VCN-MGMT-Failover

VNIC를 부동 VCN으로 마이그레이션

두 SDDC의 각 ESXi 호스트에 대해 다음 단계를 수행합니다.
  1. 액세스 ESXi 호스트 세부정보: OCI 콘솔에서 컴퓨트, ESXi 호스트로 이동합니다.
  2. 기존 VNIC 연결 삭제: 각 호스트에 대해 VCN 기본 또는 VCN-보조에서 VLAN 201 이상과 연관된 VNIC를 삭제합니다.

    주:

    이전 VNIC가 존재하는 동안에는 동일한 VLAN에 대해 새 VNIC를 만들 수 없으므로 이 단계는 필수입니다.
  3. 부동 VCN에서 VNIC 재생성:
    • 해당 부동 VCN의 각 VLAN에 대해 새 VNIC를 만듭니다.
      • OCI 전용 리전 A에서 VCN-MGMT-Active 사용
      • OCI 전용 리전 B에서 VCN-MGMT-Failover 사용
    • 적합한 -NEW 접미어로 태그 지정된 VLAN을 선택하여 원본과 구분합니다.

    호스트당 VNIC 둘 다에 대해 이 프로세스를 반복합니다. 체계적인 접근 방식을 권장합니다. VLAN 201의 경우 vnic0 및 vnic1로 시작하고, 교체를 완료한 후 다음 VLAN을 진행하십시오.

    보조 사이트 호스트에 대한 특수 고려 사항

    기본 사이트에서 호스트에 대한 VNIC를 마이그레이션한 후 보조 사이트의 모든 호스트에 대해 프로세스를 반복합니다. 그러나 한 가지 주요 세부 사항은 다음과 같습니다.

    • 보조 사이트의 vSphere 관리 구성 요소는 처음에 임시 VLAN(예: VLAN-Stretched-Cls-Mgmt-vSphere-TEMP)에 배치되었습니다.
    • 전환 중 이 임시 VLAN은 유지할 수 있습니다. 확장된 vSAN 기능에 영향을 주지 않으며 필요한 경우 vCenter 및 NSX 구성 요소에 대한 폴백 액세스를 제공합니다.

    이 임시 VLAN을 유지하면 VNIC 및 네트워크 마이그레이션 워크플로우 중 관리 액세스가 중단되지 않습니다.

    연결성 영향 및 복구

    VNIC 업데이트 중 vCenter, NSX Manager 또는 ESXi 호스트에 대한 임시 연결 손실이 예상됩니다. Recovery를 수행하려면 다음과 같이 하십시오.

    1. DRG 연결 확인: 해당 관리 VCN(활성 및 페일오버 모두)이 해당 DRG(동적 경로 지정 게이트웨이)에 연결되어 있는지 확인합니다.
    2. 경로 테이블 업데이트:
      • DRG를 가리키도록 각 Management VCN의 마스터 경로 테이블을 업데이트합니다.
      • 배스천 서브넷 경로 테이블을 업데이트하여 VCN 간 및 여러 지역 간 관리 트래픽의 경로가 올바르게 지정되도록 합니다.
    3. 액세스 검증:
      • 경로를 업데이트한 후 배스천 호스트에서 모든 관리 인터페이스에 대한 액세스를 복원해야 합니다.
      • 리소스에 연결할 수 없는 상태로 남아 있는 경우 NSG 규칙을 다시 확인하고 VCN 간 전달을 경로 지정합니다.

    사후 vNIC 마이그레이션 정리

    VNIC 마이그레이션이 완료되면 다음을 수행합니다.

    • 172.45.0.0/16 CIDR 블록에 속하는 VCN-Primary 및 VCN-Secondary에서 사용되지 않은 VLAN을 모두 제거합니다.
    • 보조 CIDR(172.45.0.0/16)은 더 이상 사용되지 않으므로 VCN-Primary에서 분리합니다.

    OCI는 활성 리소스(VNIC, 서브넷 또는 VLAN)에서 CIDR 분리를 사용하지 않는 경우에만 CIDR 분리를 허용합니다.

    • OCI 콘솔의 SDDC 리소스 페이지에 경고 표시기가 표시될 수 있습니다. Oracle Cloud VMware Solution 서비스가 VCN-Primary에 처음 배치된 구성요소를 더 이상 추적하지 않기 때문입니다.

    새 VCN 연결에 대한 라우팅 업데이트

    1. OCI 전용 리전 A의 DRG에 VCN-MGMT-Active를 연결합니다.
    2. 경로 테이블 업데이트:
      • VCN-MGMT-Active의 경우: 기본 경로(0.0.0.0/0)를 DRG로 지정합니다.
      • VCN-Primary의 배스천 서브넷의 경우: VMware vCenter 및 VMware NSX Manager에 계속 액세스할 수 있도록 DRG를 가리키도록 경로 테이블을 업데이트합니다.

    이러한 변경이 수행된 후 OCI Dedicated Region A의 VMware vCenter 및 VMware NSX Manager는 이제 기본 인터페이스가 다른 VCN에 상주하더라도 Bastion 호스트에서 연결할 수 있어야 합니다.

DRS 선호도 규칙, HA 및 VMware vSAN 스토리지 정책 구성

확장된 클러스터가 완전히 작동하고 두 사이트 모두에서 네트워킹이 안정적이면 DRS(Distributed Resource Scheduler), HA(고가용성)를 구성하고 사이트 인식 VMware vSAN 스토리지 정책을 작업 로드 및 VM(관리 가상 머신)에 지정합니다.

이러한 구성은 장애 도메인 간에 VM을 최적으로 배치하고 사이트 장애 시 자동 복구를 가능하게 합니다.

VM을 확장된 클러스터로 이전

먼저 모든 관리 VM 및 테스트 작업 로드 VM을 새로 생성된 스트레치된 클러스터로 마이그레이션합니다.

  • vMotion를 사용하여 VM을 원래 사이트별 클러스터에서 확장된 클러스터로 이동합니다.
  • 모든 항목이 올바르게 구성된 경우(네트워킹, 스토리지, 포트 그룹) VM 마이그레이션은 아무 문제 없이 완료되어야 합니다.

기본 NSX DRS 규칙이 있고 MUST로 설정된 경우 제거합니다. 이는 HA 작업을 방해하고 NSX Edge 노드 및 NSX Manager VM의 페일오버를 방지할 수 있습니다.

VM 및 호스트 그룹 만들기

작업 로드 배치에 대한 선호도 그룹 정의:

  1. 호스트 그룹 만들기:
    • 기본 사이트에 속하는 그룹 호스트입니다.
    • 보조 사이트에 속하는 호스트를 그룹화합니다.
  2. VM 그룹 생성:
    • 각 사이트 내의 호스트에 상주해야 하는 그룹 관리 VM(예: vCenter, NSX 관리자, NSX Edge 노드, HCX 관리자 등)입니다.
    • 마찬가지로 모든 워크로드 VM을 함께 그룹화합니다(모든 테스트 VM의 경우).

VM/호스트 유사성 규칙 정의

그룹 정의 후:

  • VM-to-Host affinity rules를 만들어 VM이 의도한 사이트의 호스트에 위치하도록 합니다.
  • 호스트에서 VM 실행 규칙을 사용하여 페일오버 시나리오에서 HA 유연성을 제공합니다.
  • 관리 VM 및 작업 로드 VM 그룹에 대해 이러한 규칙을 만듭니다.

이 설정은 정상 작동 중에 각 사이트가 의도한 작업 로드를 호스트하지만 호스트 또는 사이트 실패 시 자동 복구를 허용하도록 합니다.

고가용성(HA) 사용
  • 선호도 규칙이 적용된 후 클러스터 레벨에서 HA가 사용으로 설정되었는지 확인합니다.
  • 호스트 실패 이벤트 시 VM을 다시 시작하는 기본 옵션은 전체 사이트 중단을 포함하여 예상치 않은 실패 중 VM이 다시 시작되도록 합니다.

확장된 vSAN 스토리지 정책 만들기 및 적용

확장된 구성의 두 사이트 간에 데이터 중복성을 보장하려면 새 vSAN SBPM(저장소 기반 정책 관리) 정책을 정의합니다. 이 정책은 VM 데이터가 결함 도메인 및 목격자 사이트에 분산되는 방식을 제어합니다.

정책 내에서 다음 배치 규칙을 구성합니다.

  • 저장 영역 유형: vSAN
  • Site Disaster Tolerance(사이트 재해 허용 한도): 사이트 미러링 – 확장된 클러스터
  • 허용 실패: 데이터 중복이 없습니다.
  • 객체당 디스크 스트라이프 수: 1
  • 객체에 대한 IOPS 제한: 0

다른 옵션은 모두 기본값으로 둡니다.

정책이 생성되면 다음을 수행합니다.

  1. 확장된 클러스터 내의 모든 테스트 및 관리 VM에 정책을 적용합니다.
  2. Monitor, vSAN, Resyncing Objects로 이동하여 재동기화 프로세스를 관찰하고 추적합니다.
  3. 재동기화가 완료된 후 객체 배치를 확인하여 정책이 예상대로 작동하는지 확인합니다.
    • 하나의 복제 객체는 기본 사이트에 있습니다.
    • 두번째 복제 객체는 보조 사이트에 있습니다.
    • 증인 구성 요소는 원격 목격자 영역에 있습니다.

모든 VM은 처음에 비준수로 표시됩니다. 각 VM 또는 VM 그룹을 선택하고 새로 생성된 확장 정책을 수동으로 지정하여 준수하도록 합니다.

또한 Monitor, vSAN, Resyncing Objects and Virtual Objects로 이동합니다. 재동기화 프로세스가 완료되면 각 VM의 가상 객체가 기본 사이트, 보조 사이트 및 Witness 노드에 올바르게 배포되어 확장된 클러스터 설계에 대한 완전한 준수를 검증해야 합니다.