Red Hat Summit2.2. DCN 아키텍처의 네트워킹 고려 사항
다음 기능은 현재 DCN 아키텍처에서 지원되지 않습니다.
- DPDK 노드의 DHCP
- TC Flower Hardware Offload의 conntrack
TC Flower Hardware Offload용 conntrack은 DCN에서 기술 프리뷰로 사용할 수 있으므로 이러한 솔루션을 함께 사용하면 Red Hat에서 완전히 지원되지 않습니다. 이 기능은 테스트를 위해 DCN에서만 사용해야 하며 프로덕션 환경에 배포해서는 안 됩니다. 기술 프리뷰 기능에 대한 자세한 내용은 적용 범위 세부 정보를 참조하십시오.
다음 ML2/OVS 기술이 지원됩니다.
- DPDK 노드에서 DHCP가 없는 OVS-DPDK
- SR-IOV
- TC는 conntrack 없이 하드웨어 오프로드를 발생시킵니다.
- 에지에 네트워크터 노드가 있는 Neutron 가용성 영역(AZ)과 사이트당 하나의 AZ
- 라우팅된 공급자 네트워크
다음 ML2/OVN 네트워킹 기술이 완전히 지원됩니다.
- DPDK 노드에서 DHCP가 없는 OVS-DPDK
- SR-IOV (DHCP 제외)
- TC는 conntrack 없이 하드웨어 오프로드를 발생시킵니다.
- 라우팅된 공급자 네트워크
Neutron AZ가 지원되는 OVN GW(네트워크 노드)
중요OVNCMSOptions: 'enable-chassis-as-gw'를 설정하고OVNAvailabilityZone매개변수에 하나 이상의 AZ 값을 제공하여 모든 라우터 게이트웨이 포트가 OpenStack 컨트롤러 노드에 있는지 확인합니다. 이러한 작업을 수행하면 라우터가 라우터 게이트웨이 포트의 잠재적인 호스트로 모든 섀시를 예약하지 않습니다. 자세한 내용은 Red Hat OpenStack Platform 네트워킹 구성에서 ML2/OVN을 사용하여 네트워크 서비스 가용성 영역 구성을 참조하십시오.
또한 다음을 고려해야 합니다.
- 네트워크 대기 시간: RTT(Round-trip Time)로 측정된 대기 시간을 조정하여 허용 가능한 성능을 유지하기 위해 예상되는 동시 API 작업 수를 조정합니다. 최대 TCP/IP 처리량은 RTT에 비례하지 않습니다. 커널 TCP 매개변수를 조정하여 높은 대역폭으로 대기 시간이 긴 연결로 일부 문제를 완화할 수 있습니다. 사이트 간 통신이 100ms를 초과하면 Red Hat 지원에 문의하십시오.
- 네트워크 삭제: 에지 사이트에서 중앙 사이트에 일시적으로 연결이 끊어지면 중단 기간 동안 영향을 받는 에지 사이트에서 OpenStack 컨트롤 플레인 API 또는 CLI 작업을 실행할 수 없습니다. 예를 들어 에지 사이트의 컴퓨팅 노드는 결과적으로 인스턴스의 스냅샷을 생성하거나 인증 토큰을 발행하거나 이미지를 삭제할 수 없습니다. 일반 OpenStack 컨트롤 플레인 API 및 CLI 작업은 이 중단 중에 계속 작동하고 작동 중인 다른 에지 사이트를 계속 제공할 수 있습니다. 이미지 유형: Ceph 스토리지를 사용하여 DCN 아키텍처를 배포할 때 원시 이미지를 사용해야 합니다.
이미지 크기 조정:
- 오버클라우드 노드 이미지 - Overcloud 노드 이미지가 중앙 언더클라우드 노드에서 다운로드됩니다. 이러한 이미지는 프로비저닝 중에 중앙 사이트에서 에지 사이트로 필요한 모든 네트워크를 통해 전송되는 대용량 파일입니다.
인스턴스 이미지: 에지에 블록 스토리지가 없는 경우 이미지 서비스 이미지는 처음 사용하는 동안 WAN을 통과합니다. 이미지는 나중에 사용할 수 있도록 대상 에지 노드에 로컬로 복사되거나 캐시됩니다. Glance 이미지에는 크기 제한이 없습니다. 전송 시간은 사용 가능한 대역폭 및 네트워크 대기 시간에 따라 다릅니다.
에지에 블록 스토리지가 있는 경우 이미지가 비동기식으로 복사되어 에지에서 더 빠르게 부팅됩니다.
- 공급자 네트워크: DCN 배포에 권장되는 네트워킹 접근 방식입니다. 원격 사이트에서 공급자 네트워크를 사용하는 경우 Networking 서비스(neutron)가 사용 가능한 네트워크를 연결할 수 있는 위치에 제한이나 검사를 수행하지 않는 것을 고려해야 합니다. 예를 들어 에지 사이트 A에서만 공급자 네트워크를 사용하는 경우 에지 사이트 B의 공급자 네트워크에 연결하지 않도록 해야 합니다. 이는 이를 컴퓨팅 노드에 바인딩할 때 공급자 네트워크에 검증 검사가 없기 때문입니다.
- 사이트별 네트워크: 특정 사이트에 특정 네트워크를 사용하는 경우 DCN 네트워킹의 제한이 발생합니다. 컴퓨팅 노드와 함께 중앙 집중식 중성자를 배포할 때 특정 컴퓨팅 노드를 원격 노드로 식별하는 트리거가 없습니다. 결과적으로 컴퓨팅 노드는 다른 컴퓨팅 노드 목록을 수신하고 서로 자동으로 터널을 형성합니다. 터널은 중앙 사이트를 통해 에지에서 에지로 구성됩니다. VXLAN 또는 Geneve를 사용하는 경우 모든 사이트의 모든 컴퓨팅 노드는 로컬 또는 원격인지 여부에 관계없이 다른 모든 컴퓨팅 노드 및 컨트롤러 노드와 터널을 형성합니다. 어디에서나 동일한 중성자 네트워크를 사용하는 경우에는 문제가 되지 않습니다. VLAN을 사용하는 경우 neutron은 모든 컴퓨팅 노드에 동일한 브릿지 매핑이 있고 모든 VLAN을 모든 사이트에서 사용할 수 있을 것으로 예상합니다.
- 추가 사이트: 중앙 사이트에서 추가 원격 사이트로 확장해야 하는 경우 Red Hat OpenStack Platform director의 openstack CLI를 사용하여 새 네트워크 세그먼트와 서브넷을 추가할 수 있습니다.
- 에지 서버가 사전 프로비저닝되지 않은 경우 라우팅된 세그먼트에서 인트로스펙션 및 프로비저닝을 위해 DHCP 릴레이를 구성해야 합니다.
- 라우팅은 클라우드 또는 각 에지 사이트를 허브에 연결하는 네트워킹 인프라에 구성해야 합니다. 각 Red Hat OpenStack Platform 클러스터 네트워크(외부, 내부 API 등)에 L3 서브넷을 할당하는 네트워킹 설계를 구현해야 합니다.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}