OpenStack Neutron용 VMware NSX-T Data Center 플러그인 릴리스 정보

OpenStack Neutron용 VMware NSX-T Data Center 플러그인 | 2020년 4월 이 릴리스 정보의 추가 사항 및 업데이트 사항을 확인하십시오.

릴리스 정보에 포함된 내용

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

• 릴리스 호환성
• OpenStack Neutron용 VMware NSX-T Data Center 플러그인의 새로운 사항
• NSX-T OpenStack Neutron 플러그인 3.0 제한 사항
• 알려진 문제

릴리스 호환성

• 관리 API용 Neutron 플러그인(명령형 API)은 다음과 같습니다.
  • OpenStack Stein 및 OpenStack Rocky와 호환 
  • VIO 5.1.0.4, VIO 6.0.0.1과 호환(알려진 제한 사항 참조)
• 정책 API용 Neutron 플러그인(선언적 API)은 다음과 같습니다.
  • OpenStack Stein과 호환(다른 벤더 OpenStack 버전은 이후에 추가될 수 있음)
  • VIO 6.0.0.1과 호환(알려진 제한 사항 참조)
• VIO 6.0.0.1과의 상호 운용성에는 알려진 제한 섹션에 명시된 알려진 문제가 있습니다.
• NSX-T 3.0 OpenStack Neutron 플러그인에서 제공하는 새 기능은 이전 버전과 호환되는 6.0.0.1 및 VIO 5.1.0.4에서 사용할 수 없습니다.

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

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

• 정책 API용 Neutron 플러그인에서 IPv6 로드 밸런서 지원
  이를 통해 Octavia 또는 LBaaSv2를 사용할 때 OpenStack 통합에서 IPv6를 사용하도록 설정할 수 있습니다.
   
• 정책 API용 Neutron 플러그인에서 IPv6 IP 블록 지원
   
• 정책 API용 Neutron 플러그인에서 VPNaaS 지원
  이를 통해 OpenStack의 Tier-1 게이트웨이에서 NSX-T VPN 서비스를 사용할 수 있습니다.
   
• 정책 API용 Neutron 플러그인에서 vRF-lite를 외부 네트워크 지원
  NSX-T 3.0에서 Tier-0에는 여러 vRF-lite가 있을 수 있습니다. 다중 테넌시를 용이하게 하고 리소스 할당을 개선하기 위해 Tier-0을 외부 네트워크에 매핑하기 위한 OpenStack 모델이 Tier-0 vRF-lite로 확장되었습니다.
   
• 정책 API용 Neutron 플러그인의 OpenStack Neutron 라우터(NAT 없음)에서 모든 정적 경로를 보급하는 기능.
  이 기능은 연결된 경로 외에 NAT OpenStack Neutron 라우터가 없는 모든 정적 경로를 보급하는 설정을 제공합니다.
   
• 정책 API용 Neutron 플러그인에서 방화벽 규칙 syslog 부분의 프로젝트 정보 부분을 유지할 수 있습니다.
  NSX-T에서는 테넌시 정보를 제공하기 위해 방화벽 데이터부 syslog(허용/거부)의 일부로 규칙 태그를 허용합니다. 이 향상된 기능을 통해 프로젝트를 방화벽 로그의 일부로 사용할 수 있습니다. 이렇게 하면 프로젝트별로 로그를 보다 쉽게 심사하고 다중 테넌시를 관리할 수 있습니다.

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

• NSX-T 2.5
• NSX-T 2.4
• NSX-T 2.3
• NSX-T 2.2
• NSX-T 2.1
• NSX-T 2.0
• NSX-T 1.1

알려진 제한 사항

• VIO 6.0.0.1을 NSX-T 3.0과 함께 사용하는 경우 몇 가지 알려진 제한 사항이 발생합니다. (이러한 문제는 모두 VIO 6.0.0.1과 함께 제공되는 관리되지 않는 OpenStack Neutron 플러그인의 플랫폼 변경 사항으로 인해 발생합니다.)
  • 포트의 관리자 상태를 변경하려고 하면 일관되지 않은 동작이 발생합니다. 기본 이유는 VIO 6.0.0.1의 OpenStack Neutron 플러그인이 고려하지 않는 관리 상태가 정책에 추가되었기 때문입니다.
  • DevOps 워크플로에서 동시 스택 생성/삭제가 진행되면서 로드 밸런서 삭제가 실패할 수 있습니다(Terraform/Rally/Heat 사용). 해결 방법은 문제를 일으키는 로드 밸런서를 식별하고 다시 삭제하는 것입니다.
• VIO 6.0.0.1 및 VIO 5.0.0.4는 VDS 7.0에서 NSX-T를 지원하지 않으며 N-VDS를 통해 NSX-T를 배포해야 합니다.
• 구성된 Edge 업링크 프로파일 "전송 VLAN" 및 배포된 VLAN 네트워크 둘 다에 동일한 VLAN ID가 설정되면 부작용이 발생할 수 있습니다. 이 구성은 사용하면 안 됩니다. "전송 VLAN"과 배포된 VLAN 네트워크 간에 중복되는 VLAN ID를 구성하면 단지 0이 아니라, MDProxy 및 DHCP의 문제가 표시됩니다. 
• DHCP를 사용하도록 설정한 2개 이상의 서브넷을 네트워크에 추가할 수 없습니다. 
• 동일한 네트워크에 두 개의 라우터를 추가할 수 없습니다. 
• 포트당 최대 9개의 보안 그룹을 연결할 수 있습니다. 이 제한 사항은 플랫폼의 최대 15개 태그/포트 때문입니다. 9개는 SG에 사용할 수 있습니다. 
• 메타데이터는 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 규칙은 VIP의 트래픽에 적용되지 않습니다.
• NSX-T Data Center는 풀별 세션 지속성 프로파일을 지원하지 않습니다. 계층 7 규칙을 사용하여 VIP가 여러 풀로 트래픽을 라우팅하도록 할 경우 이러한 풀의 지속성 프로파일 설정은 적용되지 않습니다.

알려진 문제

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

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

  해결 방법: SNAT가 발생하기 전에 송신 규칙이 적용되고, DNAT가 발생한 후에 수신 규칙이 적용된다는 사실을 고려하여 규칙을 정의했는지 확인하십시오.

  다음은 허용 및 거부 규칙 둘 다에 적용되는 참고 사항입니다. 

  수신 FWaaS 규칙 

  비 SNAT 라우터 뒤의 소스 

  • 소스 IP는 내부 서버 IP 또는 내부 서브넷 CIDR이어야 합니다.

  SNAT 라우터 뒤의 소스 

  • 소스 서버가 플로팅 IP에 연결된 경우 플로팅 IP 주소를 사용합니다. 

  • 그렇지 않은 경우 소스 라우터의 게이트웨이 IP를 사용합니다. 

  외부 소스 

  • 실제 소스 IP 주소 또는 CIDR을 사용합니다. 

  대상

  • NSX-T Edge 방화벽이 NAT 다음에 적용되므로 내부 서버 IP 또는 내부 서브넷 CIDR을 사용합니다. 

  송신 FWaaS 규칙 

  소스 IP 

  • 이 경우 NSX-T Edge 방화벽이 NAT 이전에 적용되므로 내부 서버 IP 또는 내부 서브넷 CIDR을 사용합니다. 

  대상 IP 

  • 외부 대상이면 실제 소스 IP 또는 CIDR을 사용합니다. 

  • 비 SNAT 라우터 뒤의 대상이면 대상 IP는 내부 서버 IP 또는 내부 서브넷 CIDR이어야 합니다. 

  • SNAT 라우터 뒤의 대상이면 대상 서버가 플로팅 IP를 통해 노출되어야 합니다. 플로팅 IP를 FWaaS 규칙의 대상 IP로 사용해야 합니다. 

• 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의 트래픽을 허용 목록에 포함합니다.
• 수신기에 대한 기본 풀을 설정한 후 LB VIP에서 트래픽이 수신되지 않습니다.

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

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

  해결 방법:

  1. 수신기에서 풀을 제거하거나 삭제합니다.
  2. 풀에 수신기를 설정하거나 수신기 ID를 설정하여 새 풀을 생성합니다.
• 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는 드라이버 오류에 대한 세부 정보를 표시할 수 없습니다.

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