이 시나리오에서는 기본 사이트 1이 예약된 유지 보수 또는 계획되지 않은 전원 실패로 인해 작동 중단됩니다. 모든 워크로드가 보조 사이트 2(승격된 기본 사이트)에서 실행되고 트래픽은 사이트 2의 UDLR 및 NSX Edge를 통해 라우팅됩니다. 이제 원래 기본 사이트 1은 다시 작동되고 NSX 관리자는 NSX 구성 요소를 복구하고 모든 워크로드를 기본 사이트 1로 복원하려고 합니다.

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

사전 요구 사항

  • NSX Data Center 6.4.5 이상이 사이트 1과 2 둘 다에 설치되어 있습니다.
  • 사이트 1과 2의 vCenter Server가 고급 연결 모드를 사용하여 배포됩니다.
  • 사이트 1 및 사이트 2에서 다음 조건이 충족됩니다.
    • 애플리케이션별 보안 정책이 아닌 보안 정책(있는 경우)은 비NSX 방화벽에서 구성됩니다.
    • 애플리케이션별 방화벽 규칙이 아닌 방화벽 규칙(있는 경우)은 비NSX 방화벽에서 구성됩니다.
    • ECMP가 UDLR에서 사용하도록 설정되어 있고 모든 트래픽을 허용하는지 확인하기 위해 방화벽이 ESG 둘 다에서 사용하지 않도록 설정되어 있습니다.
  • 사이트 2(기본으로 승격)에서는 페일백 프로세스를 시작하기 전에 범용 논리적 구성 요소가 변경되지 않습니다.

프로시저

  1. 기본 사이트 1이 다시 작동되면 NSX Manager 및 컨트롤러 클러스터 노드의 전원이 켜져 있고 실행 중인지 확인합니다.
    1. 네트워킹 및 보안(Networking & Security) > 대시보드(Dashboard) > 개요(Overview)로 이동합니다.
    2. 드롭다운 메뉴에서 기본 NSX Manager를 선택합니다.
    3. 시스템 개요 창에서 NSX Manager 및 컨트롤러 클러스터 노드의 상태를 확인합니다.
      NSX Manager 및 컨트롤러 노드 옆에 있는 채워진 녹색 점은 NSX 구성 요소가 둘 다 전원이 켜져 있고 실행 중임을 의미합니다.
  2. 페일백 프로세스를 시작하기 전에 다음을 확인합니다.
    1. 설치 및 업그레이드 페이지에서 관리(Management) > NSX Manager(NSX Managers)로 이동한 후 사이트 둘 다의 NSX Manager에 기본 역할이 있는지 확인합니다.
    2. NSX Controller 노드 페이지에서 UCC(범용 컨트롤러 클러스터) 노드가 사이트 둘 다에 존재하는지 확인합니다.
  3. 사이트 2(승격된 기본)와 연결된 3개의 UCC 노드를 모두 종료합니다.
  4. NSX Controller 노드 페이지에서 사이트 2(승격된 기본)와 연결된 3개의 UCC 노드를 모두 삭제합니다.
    팁: 다음 API 호출을 실행함으로써 NSX REST API를 사용하여 한 번에 하나씩 컨트롤러 노드를 제거할 수 있습니다. https://NSX_Manager_IP/api/2.0/vdn/controller/{controllerID} 그렇지만 다음 API 호출을 실행하여 마지막 컨트롤러 노드를 강제로 삭제합니다. https://NSX_Manager_IP/api/2.0/vdn/controller/{controllerID}?forceRemoval=true
  5. 다음 단계를 계속 진행하기 전에 사이트 2(승격된 기본)의 범용 구성 요소가 변경되지 않았는지 확인합니다.
  6. 사이트 2(승격된 기본)의 NSX Manager에서 기본 역할을 제거합니다.
    1. 설치 및 업그레이드 페이지에서 관리(Management) > NSX Manager(NSX Managers)로 이동합니다.
    2. 사이트 2에서 NSX Manager를 선택하고 작업(Actions) > 기본 역할 제거(Remove Primary Role)를 클릭합니다.
      기본 역할을 제거하기 전에 사이트 2의 NSX Manager가 소유하는 컨트롤러가 삭제되었는지 확인하라는 메시지가 표시됩니다.
    3. 예(Yes)를 클릭합니다.
      사이트 2의 NSX Manager에 전송 역할이 지정됩니다.
  7. 사이트 1의 기본 NSX Manager에서 연결된 보조 NSX Manager를 제거합니다.
    1. NSX Manager 페이지에서 사이트 1과 연결된 NSX Manager를 선택합니다.
    2. 작업(Actions) > 보조 Manager 제거(Remove Secondary Manager)를 클릭합니다.
    3. NSX Manager에 액세스할 수 없는 경우에도 작업 수행(Perform Operation even if NSX Manager is inaccessible) 확인란을 선택합니다.
    4. 제거(Remove)를 클릭합니다.
  8. 전송 중인 사이트 2의 NSX Manager를 사이트 1에 있는 기본 NSX Manager의 보조로 등록합니다.
    경고: 로컬 송신이 UDLR 제어 VM(Edge Appliance VM)에서 사용하지 않도록 설정되어 있으므로 제어 VM은 자동으로 삭제됩니다. 따라서 사이트 2의 NSX Manager(현재 전송 중인 역할)를 보조 역할에 등록하기 전에 사이트 2의 컨트롤러 클러스터 노드가 삭제되었는지 확인합니다. 컨트롤러 클러스터 노드가 삭제되지 않으면 네트워크 트래픽 중단이 발생할 수 있습니다.
    1. 설치 및 업그레이드 페이지에서 관리(Management) > NSX Manager(NSX Managers)로 이동합니다.
    2. 사이트 1과 연결된 NSX Manager를 선택합니다.
    3. 작업(Actions) > 보조 Manager 추가(Add Secondary Manager)를 클릭합니다.
    4. 사이트 2과 연결된 NSX Manager를 선택합니다.
    5. 사이트 2에 있는 NSX Manager의 사용자 이름 및 암호를 입력하고 보안 인증서를 수락합니다.
    6. 추가(Add)를 클릭합니다.
    이러한 모든 하위 단계를 완료한 후 다음 결과를 확인합니다.
    • 사이트 1의 NSX Manager에는 기본 역할이 지정되고 사이트 2의 NSX Manager에는 보조 역할이 지정되어 있습니다.
    • 사이트 2의 NSX Manager에서는 3개의 섀도 컨트롤러 노드가 연결 끊김 상태로 나타납니다. 기본 또는 독립형 Manager에서만 컨트롤러 클러스터 속성을 읽거나 업데이트할 수 있습니다.라는 메시지가 표시됩니다.

      이 메시지는 사이트 2의 보조 NSX Manager가 사이트 1의 기본 NSX Manager에 있는 범용 컨트롤러 클러스터 노드에 연결하도록 설정할 수 없음을 의미합니다. 그러나 몇 초 후에 연결이 다시 설정되고 상태가 연결됨으로 변경됩니다.

  9. 사이트 1의 UDLR에 있는 제어 VM(Edge Appliance VM) 및 NSX Edge의 전원을 켭니다.
    1. 네트워킹(Networking) > VM(VMs) > 가상 시스템(Virtual Machines)으로 이동합니다.
    2. UDLR 제어 VM의 VM 이름(VM ID)을 마우스 오른쪽 버튼으로 클릭하고 전원 켜기(Power on)를 클릭합니다.
    3. 전원을 켤 Edge VM에 대해 (b)단계를 반복합니다.
    4. 다음 단계를 계속 진행하기 전에 UDLR 제어 VM 및 Edge VM이 작동되고 실행될 때까지 기다립니다.
  10. 사이트 2의 보조 NSX Manager와 연결된 UDLR 제어 VM(Edge Appliance VM)이 자동으로 삭제되었는지 확인합니다.
    1. 네트워킹 및 보안(Networking & Security) > NSX Edge(NSX Edges)로 이동합니다.
    2. 보조 NSX Manager를 선택하고 UDLR을 클릭합니다.
    3. 상태 페이지에서 UDLR에 배포된 Edge Appliance VM이 없음을 확인합니다.
  11. 컨트롤러 서비스가 보조 사이트 2와 동기화되도록 기본 사이트 1에서 NSX Controller 상태를 업데이트합니다.
    1. 설치 및 업그레이드 페이지에서 NSX Manager(NSX Managers)를 클릭합니다.
    2. 사이트 1에서 기본 NSX Manager를 선택합니다.
    3. 작업(Actions) > 컨트롤러 상태 업데이트(Update Controller State)를 클릭합니다.
  12. 워크로드 VM을 사이트 2에서 사이트 1로 마이그레이션합니다.
    참고: 워크로드 VM은 사이트 2에 계속 존재합니다. 따라서 워크로드 VM을 사이트 1에 수동으로 마이그레이션해야 합니다.

결과

보조 사이트(사이트 2)에서 기본 사이트(사이트 1)로의 모든 NSX 구성 요소 및 워크로드에 대한 수동 페일백이 완료되었습니다.

다음에 수행할 작업

사이트 1에서 다음 단계를 수행하여 기본 사이트 1로의 페일백이 100% 완료되었는지 확인합니다.
  1. NSX Manager에 기본 역할이 있는지를 확인합니다.
  2. 제어 VM(Edge Appliance VM)이 UDLR에서 배포되는지 여부를 확인합니다.
  3. 모든 컨트롤러 클러스터 노드의 상태가 연결됨인지 여부를 확인합니다.
  4. NSX에 대해 준비된 각 호스트 클러스터에서 통신 상태 점검을 수행합니다.
    1. 설치 및 업그레이드(Installation and Upgrade) > 호스트 준비(Host Preparation)로 이동합니다.
    2. 사이트 1에서 NSX Manager를 선택합니다.
    3. 한 번에 하나씩 클러스터를 선택하고 클러스터의 통신 채널 상태가 [UP]인지 확인합니다.
    4. 클러스터의 각 호스트에 대해, 호스트의 통신 채널 상태가 [UP]인지 확인합니다.
    5. 호스트 준비 상태가 녹색인지 여부를 확인합니다.
  5. UDLR 제어 VM(Edge Appliance VM)의 CLI 콘솔에 로그인하고 다음 단계를 수행합니다.
    1. show ip bgp neighbors 명령을 실행하여 모든 BGP 인접 네트워크가 설정되어 있는지와 해당 상태가 [UP]인지 확인합니다.
    2. show ip route bgp 명령을 실행하여 모든 BGP 인접 네트워크에서 모든 BGP 경로가 학습되고 있는지를 확인합니다.

사이트 1로의 전체 페일백 후에 기본 사이트 1에서 모든 워크로드가 실행되고 트래픽은 사이트 1의 UDLR 및 NSX Edge를 통해 라우팅됩니다.