이 시나리오에서는 팰로앨토의 기본 사이트 1에서 자연재해가 발생하고 사이트 1이 완전히 작동 중단됩니다. NSX 관리자는 오스틴에서 보조 사이트 2로의 수동 페일오버를 수행합니다.

기본 사이트가 예측할 수 없는 상황으로 인해 작동 중단될 경우 관리자는 실제 실패가 발생하기 전에 페일오버를 준비할 수 없습니다.

NSX 관리자는 다음과 같은 주요 목표를 충족하려고 합니다.
  • 최소화한 다운타임으로 사이트 2에서 전체 사이트 페일오버를 수행합니다.
  • 페일오버 후에 사이트 2에서 사이트 1 애플리케이션 IP 주소를 유지합니다.
  • 사이트 2에서 모든 Edge 인터페이스 설정 및 BGP 프로토콜 구성 설정을 자동으로 복구합니다.
참고:
  • 관리자는 vSphere Web Client를 사용하거나 NSX REST API를 실행하여 수동으로 페일오버 작업을 수행할 수 있습니다. 또한 관리자는 페일오버 동안 실행할 API가 포함된 스크립트 파일을 실행하여 일부 페일오버 작업을 자동화할 수 있습니다. 이 시나리오에서는 vSphere Web Client를 사용하여 수동 페일오버 단계를 설명합니다. 그러나 임의의 단계에서 CLI 또는 NSX REST API를 사용해야 하는 경우 적절한 지침이 제공됩니다.
  • 이 시나리오에서 재해 복구 워크플로는 기본 NSX Manager 및 단일 보조 NSX Manager가 있는 이전에 설명한 토폴로지에만 해당됩니다. 다중 보조 NSX Manager가 있는 워크플로는 이 시나리오의 범위에 포함되지 않습니다.
중요: 보조 사이트 2로의 페일오버가 진행되는 동안 기본 사이트 1의 전원이 켜지면, 먼저 이 시나리오의 절차를 사용하여 페일오버 프로세스가 완료되었는지 확인합니다. 보조 사이트 2에서 클린 페일오버가 완료된 이후에만 모든 워크로드를 원래 기본 사이트 1로 복원하거나 페일백합니다. 페일백 프로세스에 대한 자세한 지침은 시나리오 3: 기본 사이트로의 전체 페일백을 참조하십시오.

사전 요구 사항

  • NSX Data Center 6.4.5 이상이 사이트 1과 2 둘 다에 설치되어 있습니다.
  • 사이트 1과 2의 vCenter Server가 고급 연결 모드를 사용하여 배포됩니다.
  • 사이트 1 및 사이트 2에서 다음 조건이 충족됩니다.
    • 애플리케이션별 보안 정책이 아닌 보안 정책(있는 경우)은 비NSX 방화벽에서 구성됩니다.
    • 애플리케이션별 방화벽 규칙이 아닌 방화벽 규칙(있는 경우)은 비NSX 방화벽에서 구성됩니다.
    • ECMP가 UDLR에서 사용하도록 설정되어 있고 모든 트래픽을 허용하는지 확인하기 위해 방화벽이 ESG 둘 다에서 사용하지 않도록 설정되어 있습니다.
  • 사이트 2에서는 다음 조건이 충족되어야 페일오버가 수행됩니다.
    • 사이트 1에서 구성된 것과 유사한 다운링크 인터페이스가 ESG에서 수동으로 구성됩니다.
    • 사이트 1에서 구성된 것과 유사한 BGP 구성이 ESG에서 수동으로 수행됩니다.
    • 기본 사이트 1이 활성 상태이거나 실행 중이면 ESG가 전원 중단 상태입니다.

프로시저

  1. 사이트 1의 기본 NSX Manager가 작동 중단되었는지 확인합니다.
    1. 설치 및 업그레이드 페이지에서 관리(Management) > NSX Manager(NSX Managers)로 이동합니다.
      • 현재 브라우저 세션에서 NSX Manager 페이지를 새로 고치면 기본 NSX Manager의 역할이 알 수 없음으로 변경됩니다.
      • vSphere Web Client에서 로그아웃했다가 다시 로그인하거나 새 vSphere Web Client 브라우저 세션을 시작하는 경우 기본 NSX ManagerNSX Manager 페이지에 더 이상 표시되지 않습니다.
    2. 네트워킹 및 보안(Networking & Security) > 대시보드(Dashboard) > 개요(Overview)로 이동합니다.
      • 현재 브라우저 세션에서 대시보드 페이지를 새로 고치는 경우 오류 메시지 NSX Manager와의 연결을 설정할 수 없습니다. 관리자에게 문의하십시오.가 표시됩니다. 이 오류는 기본 NSX Manager에 더 이상 연결할 수 없음을 의미합니다.
      • vSphere Web Client에서 로그아웃했다가 다시 로그인하거나 새 vSphere Web Client 브라우저 세션을 시작하는 경우 기본 NSX ManagerNSX Manager 드롭다운 메뉴에서 더 이상 사용할 수 없습니다.
  2. 보조 NSX Manager를 기본 역할로 승격합니다.
    1. 설치 및 업그레이드 페이지에서 관리(Management) > NSX Manager(NSX Managers)로 이동합니다.
    2. 보조 NSX Manager를 선택합니다.
    3. 작업(Actions) > 기본 NSX Manager에서 연결 끊기(Disconnect from Primary NSX Manager)를 클릭합니다. 연결 끊기 작업을 계속할지 묻는 메시지가 표시되면 예(Yes)를 클릭합니다.
      보조 NSX Manager와 기본 NSX Manager의 연결이 끊어지고 전송 역할이 적용됩니다.
    4. 작업(Actions) > 기본 역할 할당(Assign Primary Role)을 클릭합니다.
      사이트 2의 보조 NSX Manager는 기본 역할로 승격됩니다.
    경고: 로컬 송신이 UDLR에서 사용하지 않도록 설정되었으므로 UDLR 제어 VM(Edge Appliance VM)이 원래의 기본 사이트(사이트 1)에만 배포됩니다. 사이트 1이 실패하기 전에, UDLR 제어 VM을 이제는 기본 사이트로 승격된 보조 사이트(사이트 2)에서 사용할 수 없습니다. 따라서 NSX Controller 클러스터를 다시 배포하기 전에 승격된 기본 사이트(사이트 2)에서 UDLR 제어 VM을 다시 배포합니다.

    UDLR 제어 VM을 배포하기 전에 컨트롤러 노드가 배포되면 UDLR의 전달 테이블이 플러시됩니다. 이로 인해 사이트 2에서 첫 번째 컨트롤러 노드를 배포한 직후, 다운타임이 발생합니다. 이 경우 통신 중단이 발생할 수 있습니다. 이 문제를 방지하려면 NSX Controller 노드를 배포하기 전에 UDLR 제어 VM을 배포합니다.

  3. 전원이 꺼진 NSX Edge의 전원을 켜고 보조 사이트 2(승격된 기본)에서 UDLR 제어 VM(Edge Appliance VM)을 배포합니다.
    UDLR 제어 VM을 배포하는 방법에 대한 지침은 " NSX 크로스 vCenter 설치 가이드" 를 참조하십시오.
    UDLR 제어 VM을 배포하는 동안 다음 리소스 설정을 구성합니다.
    • 데이터 센터를 사이트 2로 선택합니다.
    • 클러스터/리소스 풀을 선택합니다.
    • 데이터스토어를 선택합니다.
    참고: UDLR 제어 VM을 배포하면 다음 구성 설정이 사이트 2에서 자동으로 복구됩니다.
    • BGP 프로토콜 라우팅 구성
    • BGP 암호 구성
    • 업링크 및 내부 인터페이스 설정
  4. 사이트 2(승격된 기본)에서 3개의 NSX Controller 클러스터 노드를 배포합니다.
    NSX Controller 배포 방법에 대한 자세한 지침은 " NSX 크로스 vCenter 설치 가이드" 를 참조하십시오.
  5. NSX Controller 클러스터 상태를 업데이트합니다.
    1. 설치 및 업그레이드 페이지에서 NSX Manager(NSX Managers)를 클릭합니다.
    2. 승격된 기본 NSX Manager를 선택합니다.
    3. 작업(Actions) > 컨트롤러 상태 업데이트(Update Controller State)를 클릭합니다.
  6. 사이트 2의 각 클러스터에서 라우팅 서비스를 강제로 동기화합니다.
    1. 설치 및 업그레이드 페이지에서 호스트 준비(Host Preparation)를 클릭합니다.
    2. 승격된 기본 NSX Manager를 선택합니다.
    3. 한 번에 하나씩 클러스터를 선택하고 작업(Actions) > 서비스 강제 동기화(Force Sync Services)를 클릭합니다.
    4. 라우팅(Routing)을 선택하고 확인(OK)을 클릭합니다.
  7. 워크로드 VM을 사이트 1에서 사이트 2로 마이그레이션합니다.
    참고: 워크로드 VM은 사이트 1에 계속 존재합니다. 따라서 워크로드 VM을 사이트 2에 수동으로 마이그레이션해야 합니다.

결과

NSX 구성 요소의 수동 복구 및 기본 사이트(사이트 1)에서 보조 사이트(사이트 2)로의 페일오버가 완료되었습니다.

다음에 수행할 작업

사이트 2(승격된 기본 사이트)에서 다음 단계를 수행하여 사이트 2로의 페일오버가 100% 완료되었는지 확인합니다.
  1. NSX Manager에 기본 역할이 있는지를 확인합니다.
  2. 제어 VM(Edge Appliance VM)이 UDLR에서 배포되는지 여부를 확인합니다.
  3. 모든 컨트롤러 클러스터 노드의 상태가 연결됨인지 여부를 확인합니다.
  4. 호스트 준비 상태가 녹색인지 여부를 확인합니다.
  5. UDLR 제어 VM(Edge Appliance VM)의 CLI 콘솔에 로그인하고 다음 단계를 수행합니다.
    1. show ip bgp neighbors 명령을 실행하여 모든 BGP 인접 네트워크가 설정되어 있는지와 해당 상태가 [UP]인지 확인합니다.
    2. show ip route bgp 명령을 실행하여 모든 BGP 인접 네트워크에서 모든 BGP 경로가 학습되고 있는지를 확인합니다.

사이트 2로의 전체 페일오버 후에 보조 사이트(승격된 기본)에서 모든 워크로드가 실행되고 트래픽은 사이트 2의 UDLR 및 NSX Edge를 통해 라우팅됩니다.