RSS
 

OpenStack Neutron용 VMware NSX-T Data Center 플러그인 3.1 | 2020년 10월 30일

이 릴리스 정보의 추가 사항 및 업데이트 사항을 확인하십시오.

릴리스 정보에 포함된 내용

릴리스 정보에는 다음과 같은 항목이 포함됩니다.

릴리스 호환성

  • Neutron Plugin for Management API(명령적 API) 및 정책 API(선언적 API)는 다음과 같습니다.
    • OpenStack Stein 및 OpenStack Train과 호환 
    • VIO 7.0.1 및 VIO 6.0.1과 호환
  • NSX-T 3.1 OpenStack Neutron 플러그인에서 제공하는 새 기능은 이전 버전과 호환되는 Stein 또는 VIO 6.0.1에서 사용할 수 없습니다.

호환성 및 시스템 요구 사항에 대한 자세한 내용은 VMware NSX OpenStack 플러그인 설치 및 구성 가이드와 NSX-T Data Center 설치 가이드를 참조하십시오.

OpenStack Neutron용 VMware NSX-T Data Center 플러그인의 새로운 사항

  • Management API를 사용하는 OpenStack용 NSX-T Policy Neutron 플러그인 환경으로 변환: NSX-T가 있는 OpenStack 환경을 관리 API에서 정책 API로 이동할 수 있습니다. 이렇게 하면 NSX-T 2.5 이전에 배포된 환경을 최신 NSX-T Neutron 플러그인으로 이동하고 vRF-lite와 같은 최신 플랫폼 기능을 활용할 수 있습니다.
    이 기능을 사용하려면 지원하는 VIO 버전이 있어야 합니다. 마이그레이션을 완료한 후에는 롤백할 수 없으므로 진행하기 전에 NSX-T 백업을 수행하는 것이 좋습니다.
     
  •  OpenStack Neutron 라우터에서 NAT 및 방화벽 적용 순서를 변경하는 기능: 이를 통해 배포 중에 NAT와 FWLL 중에서 작업 순서를 선택할 수 있습니다. OpenStack Neutron 라우터 수준(NSX-T에서 Tier-1로 매핑됨)에서 작업 순서를 NAT 다음에 방화벽으로 또는 방화벽 다음에 NAT 중 하나로 정의할 수 있습니다. 지정된 OpenStack 플랫폼과 정책 플러그인 전용 기능에 대한 글로벌 설정입니다.
     
  • 상태 저장 DHCPv6 지원: IPv6 워크로드를 사용할 수 있도록 3.0 및 2.5에 제공된 IPv6 기능에 추가로 제공됩니다. 이제 IP 주소 지정을 위해 SLAAC 및 DHCPv6 중에서 선택할 수 있습니다. 이것은 정책 플러그인 전용 기능입니다.

이전 버전에 대한 릴리스 정보를 확인하십시오.

알려진 제한 사항

  • 직접 설치한 경우, Ubuntu 18.04 또는 RHEL 7.7을 실행하는 컨트롤러 노드에서 Train 또는 Stein 패키지를 실행해야 합니다.
  • (RHEL 8.2에는 python 3 패키지가 필요하고 Ubuntu 20.04는 Train에 지원되지 않습니다.)
  • VIO 7.0.0은 NSX-T 3.1.0 OpenStack Neutron 플러그인과 호환되지 않습니다. VIO를 VIO 7.0.1로 업데이트하십시오.
  • 구성된 Edge 업링크 프로파일 "전송 VLAN" 및 배포된 VLAN 네트워크 둘 다에 동일한 VLAN ID가 설정되면 부작용이 발생할 수 있습니다. 이 구성은 사용하면 안 됩니다. "전송 VLAN"과 배포된 VLAN 네트워크 간에 중복되는 VLAN ID를 구성하면 단지 0이 아니라, MDProxy 및 DHCP의 문제가 표시됩니다. 
  • DHCP를 사용하도록 설정한 2개 이상의 서브넷을 네트워크에 추가할 수 없습니다. 
  • 지정된 Neutron 포트에 대해 동일한 서브넷의 여러 주소를 구성할 수 없습니다.
  • 동일한 네트워크에 두 개의 라우터를 추가할 수 없습니다. 
  • 포트당 최대 24개의 보안 그룹을 연결할 수 있습니다. 이 제한 사항은 플랫폼의 최대 30개 태그/포트 때문입니다. SG에 대해 24를 사용할 수 있습니다.
  • 메타데이터는 3000~9000 포트만 지원합니다.
  • IPv6은 정책용 NSX-T OpenStack Neutron 플러그인(NSXP)에 대해서만 지원되고 관리부 API용 NSX-T OpenStack Neutron 플러그인(비정책)에 대해서는 지원되지 않습니다.
  • 현재, QoS는 ESXi 및 KVM에 대해 "조절" 및 "DSCP 표시"를 지원합니다("CoS 표시" 또는 "최소 BW"는 지원하지 않음).
  • QoS는 하이퍼바이저를 나가는 트래픽에 적용됩니다(하이퍼바이저 내부 아님).
  • FWaaS는 동일한 Neutron 라우터의 다운링크 인터페이스 간 E/W 트래픽에 적용되지 않습니다.
  • FWaaS 규칙은 방화벽, NAT, VIP 간에 순서가 허용하는 경우에만 VIP의 트래픽에 적용됩니다.
  • NSX-T Data Center는 풀별 세션 지속성 프로파일을 지원하지 않습니다. 계층 7 규칙을 사용하여 VIP가 여러 풀로 트래픽을 라우팅하도록 할 경우 이러한 풀의 지속성 프로파일 설정은 적용되지 않습니다.

해결된 문제

  • FWaaS 규칙이 예상대로 적용되지 않습니다. NSX-v 드라이버 또는 참조 구현 드라이버에서 올바르게 작동하는 일부 규칙이 NSX-T Edge 방화벽에서 무시되는 것 같습니다.

    NSX-T에 대한 방화벽 동작은 NSX-v 및 참조 구현과 다릅니다. 즉, fwaas는 송신의 경우 NAT 이후에, 수신의 경우 NAT 이전에 수행됩니다.

  • 수신기에 대한 기본 풀을 설정한 후 LB VIP에서 트래픽이 수신되지 않습니다.

    Neutron-LBaas에서 허용하더라도 기본 풀 또는 수신기 업데이트는 NSX-T에서 구현되지 않은 작업입니다. 결과적으로 NSX-T 가상 서버의 풀이 올바르게 업데이트되더라도 NSX-T LBS는 VS ID를 사용하여 업데이트되지 않습니다.

    따라서 VS가 아직 LBS에 연결되지 않았다면 연결이 이루어지지 않습니다.

알려진 문제

  • VM이 부팅되고 DHCP 서버에서 IP를 올바르게 가져오지만, 트래픽을 전송/수신할 수 없습니다. 실제 VM IP가 Neutron에서 보고한 것과 다릅니다.

    DHCP 릴레이가 사용하도록 설정된 경우 spoofguard가 VM의 아웃바운드 트래픽을 차단할 수 있습니다.

    해결 방법: 모든 네트워크에서 포트 보안을 사용하지 않도록 설정하십시오.

  • LB VIP의 트래픽을 허용하기 위해 DFW 규칙을 명시적으로 추가해도 효과가 없습니다.

    OpenStack은 SNAT 자동 맵 모드를 사용하여 NSX-T 가상 서버를 구성합니다. 이 작업은 대상 구성원과 동일한 Tier-1 라우터 뒤에 있는 클라이언트에서 LB 연결이 발생하는 사용 사례를 충족하는 데 필요했습니다.

    이 모드에서는 로드 밸런서에서 오는 트래픽에 대한 소스 IP가 VIP 자체가 아니고 내부 전송 작업의 주소입니다. 이로 인해 OpenStack 통합 문제가 발생하지는 않습니다.

    해결 방법:

    1. 트래픽을 보안 그룹의 허용 목록에 포함합니다.
    2. NSX-T에서 LB VS가 사용하는 전송 네트워크의 IP를 찾습니다. 적어도 이 주소를 포함하는 DFW 규칙을 생성합니다. 
    3. 내부 서브넷 CIDR의 트래픽을 허용 목록에 포함합니다.
  • Neutron l2-gateway-update를 사용할 때 디바이스 이름을 업데이트할 수 없습니다.

    작업
    Neutron l2-gateway-update <l2_gw_id>--device name=<device_name>,interface_names=<interface_name>은
    <device_name>이 아직 정의되지 않은 경우 항상 실패합니다. 이 작업은 실제로 기존 디바이스에서 인터페이스를 업데이트하기 위한 것입니다.

    해결 방법: 다른 게이트웨이 디바이스를 사용해야 하는 경우 Neutron l2gw 기능에서 게이트웨이 디바이스 업데이트를 위한 솔루션을 제공하지 않기 때문에 Neutron에서 계층 2 게이트웨이를 삭제했다가 다시 생성해야 합니다.

  • 수신기를 추가한 후 Openstack 로드 밸런서가 오류 상태로 전환됩니다. 동일한 로드 밸런서에 일관된 수의 수신기가 이미 구성되어 있습니다.

    NSX-T 로드 밸런서 서비스에서 허용되는 최대 가상 서버 수를 초과하므로 이 문제가 발생합니다. 허용되는 최대 수는 로드 밸런서 서비스의 NSX-T 버전 및 크기에 따라 다릅니다. 허용되는 최대값에 대한 자세한 내용은 NSX-T에 대한 구성 최대값을 참조하십시오.

    Octavia 서비스는 로드 밸런서가 오류 상태로 전환되었다는 사실만 보고합니다. Octavia를 통해 백엔드 실패에 대한 정보를 검색할 수는 없습니다. 이 정보는 Neutron 로그에서만 사용할 수 있습니다.

    해결 방법: 이 문제에 대한 해결 방법은 없습니다.

    Octavia에서 로드 밸런서가 [오류] 상태로 전환되면 되돌릴 수 없으며 추가 작업이 허용되지 않습니다.

    그러나 기존 수신기는 계속 작동합니다.

  • "내부" 서브넷에서 OpenStack 로드 밸런서를 생성할 때 관련 논리적 스위치의 논리적 포트 작동이 종료됩니다.

    Openstack 로드 밸런서(Neutron LBaaS v2 및 Octavia 둘 다)에는 항상 로드 밸런서용 Neutron 논리적 포트를 생성하는 "네트워크 드라이버"가 있습니다.

    그러나 NSX-T 로드 밸런서 서비스는 계층 1 라우터에서 구현되므로 Neutron LBaaSv2 또는 Octavia에서 지정된 VIP 서브넷에 논리적 포트가 없습니다.

    따라서 로드 밸런서가 삭제될 때 제거되는 미사용 논리적 포트가 존재합니다.

    해결 방법: 작업 상태가 "종료"인 논리적 포트는 무해하며 무시해도 됩니다.

  • Octaivia에서 쿠키 기반 세션 지속성을 사용하여 L4 로드 밸런서를 업데이트하면 [오류] 상태의 로드 밸런서가 전송됩니다.

    풀의 세션 지속성 프로파일을 소스 IP에서 쿠키 기반으로 업데이트하면 로드 밸런서가 [오류] 상태로 전환되고 변경할 수 없게 됩니다.

    안타깝게도 Octavia 서비스는 적절한 세션 지속성 유형이 풀에 적용되고 있는지 확인하지 않습니다.

    따라서 잘못된 정보로 NSX-T를 업데이트하는 경우(TCP 가상 서버의 HTTP 쿠키 기반 세션 지속성 요청) NSX-T는 오류를 반환하며, 오류 상태의 Octavia 로드 밸런서가 전송됩니다.

    안타깝게도 Octavia는 드라이버 오류에 대한 세부 정보를 표시할 수 없습니다.

    해결 방법: 이 문제에 대한 해결 방법은 없습니다. 로드 밸런서가 [오류] 상태가 되면 변경 불가능해지고 복구되지 않습니다.

  • 정책으로 마이그레이션한 후에는 "VIP 포트"가 정책 관리자에 세그먼트 포트로 표시됩니다.

    Neutron LB 드라이버에 의해 MP에 생성된 논리적 포트는 NSX-T 정책과의 OpenStack 통합으로 VIP에 대한 세그먼트 포트가 생성되지 않더라도 정책으로 마이그레이션됩니다.

    해결 방법: 해결 방법이 없습니다. 이 추가 세그먼트 포트는 부적절하며 Neutron NSX-T 정책 플러그인에서 무시됩니다. 마이그레이션 후 안전하게 제거할 수 있습니다.

  • LB 상태 모니터를 삭제하면 "서버 측 오류: "'NoneType' 개체에 'load_balancer_id' 특성이 없습니다.”를 나타내며 실패합니다.

    이것은 VMware NSX 플러그인에 영향을 미치는 Octavia 서비스의 버그입니다. 경우에 따라 Octavia 서비스는 상태 모니터에 해당하는 풀을 검색하지 못하므로 이 오류가 트리거됩니다.

    이 버그는 현재 미해결 상태이며 https://storyboard.openstack.org/#!/story/2008231에서 추적되고 있습니다.

    해결 방법: 상태 모니터의 삭제는 다시 시도할 수 있으며 결국 성공해야 합니다.

check-circle-line exclamation-circle-line close-line
Scroll to top icon