네트워킹 가이드

Red Hat OpenStack Platform 17.0

Red Hat OpenStack Platform 네트워킹 고급 가이드

OpenStack Documentation Team

초록

일반적인 OpenStack Networking 작업을 위한 셰이크북.

머리말

참고

인스턴스를 생성하는 동안에는 RBAC(역할 기반 액세스 제어)-공유 보안 그룹을 인스턴스에 직접 적용할 수 없습니다. RBAC-shared 보안 그룹을 인스턴스에 적용하려면 먼저 포트를 생성하고, 공유 보안 그룹을 해당 포트에 적용한 다음 해당 포트를 인스턴스에 할당해야 합니다. 포트에 보안 그룹 추가를 참조하십시오.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

Red Hat 문서에 관한 피드백 제공

문서 개선을 위한 의견을 보내 주십시오. 우리가 어떻게 그것을 더 잘 만들 수 있는지 알려주십시오.

Direct Documentation feedback(DDF) 함수 사용

특정 문장, 단락 또는 코드 블록에 대한 직접 코멘트를 위해서는 DDF 함수 추가 를 사용하십시오.

  1. Multi-page HTML 형식으로 설명서를 확인합니다.
  2. 문서의 오른쪽 위에 사용자 지정 단추가 표시되는지 확인합니다.Ensure that you see the Feedback button in the upper right corner of the document.
  3. 주석하려는 텍스트 부분을 강조 표시합니다.
  4. 피드백 추가를 클릭합니다.
  5. 코멘트와 함께 피드백 추가 필드를 완료합니다.
  6. 선택 사항: 문서 팀에서 문제 해결을 위해 연락할 수 있도록 이메일 주소를 추가하십시오.
  7. 제출을 클릭합니다.

1장. OpenStack 네트워킹 소개

네트워킹 서비스(neutron)는 RHOSP(Red Hat OpenStack Platform)의 소프트웨어 정의 네트워킹(SDN) 구성 요소입니다. RHOSP 네트워킹 서비스는 가상 머신 인스턴스의 내부 및 외부 트래픽을 관리하고 라우팅, 세그먼트, DHCP 및 메타데이터와 같은 핵심 서비스를 제공합니다. 가상 네트워킹 기능 및 스위치, 라우터, 포트 및 방화벽을 관리하기 위한 API를 제공합니다.

1.1. RHOSP 네트워크 관리

RHOSP(Red Hat OpenStack Platform) 네트워킹 서비스(neutron)를 사용하면 사이트의 네트워킹 목표를 효과적으로 충족할 수 있습니다. 다음을 수행할 수 있습니다.

  • 프로젝트 내에서 VM 인스턴스에 대한 연결을 제공합니다.

    프로젝트 네트워크는 주로 일반(권한이 없는) 프로젝트를 통해 관리자의 개입 없이 네트워크를 관리할 수 있습니다. 이러한 네트워크는 완전히 가상이며 가상 라우터가 다른 프로젝트 네트워크 및 인터넷과 같은 외부 네트워크와 상호 작용해야 합니다. 프로젝트 네트워크는 일반적으로 인스턴스에 DHCP 및 메타데이터 서비스를 제공합니다. RHOSP에서는 flat, VLAN, VXLAN, GRE, GENECDHEE의 다음 프로젝트 네트워크 유형을 지원합니다.

    자세한 내용은 프로젝트 네트워크 관리를 참조하십시오.

  • VM 인스턴스를 프로젝트 외부의 네트워크에 연결합니다.

    공급자 네트워크는 프로젝트 네트워크와 같은 연결을 제공합니다. 그러나 관리(권한) 사용자만 물리적 네트워크 인프라와 상호 작용하기 때문에 해당 네트워크를 관리할 수 있습니다. RHOSP에서는 flat 및 VLAN의 다음 공급자 네트워크 유형을 지원합니다.

    프로젝트 네트워크 내에서 유동 IP 주소 또는 단일 유동 IP 주소 풀을 사용하여 VM 인스턴스로 들어오는 트래픽을 전달할 수 있습니다. 브리지 매핑을 사용하면 물리적 네트워크 이름( 인터페이스 레이블)을 OVS 또는 OVN으로 생성한 브리지에 연결하여 공급자 네트워크 트래픽이 물리적 네트워크에 도달할 수 있도록 할 수 있습니다.

    자세한 내용은 물리적 네트워크에 VM 인스턴스 연결을 참조하십시오.

  • 에지에 최적화된 네트워크를 생성합니다.

    Operator는 일반적으로 에지 배포에서 사용되는 라우팅된 공급자 네트워크를 생성하고, 하나의 세그먼트만 있는 기존 네트워크 대신 여러 계층 2 네트워크 세그먼트에 의존합니다.

    라우팅된 공급자 네트워크는 하나의 네트워크만 보기 때문에 최종 사용자를 위한 클라우드를 단순화합니다. 클라우드 운영자의 경우 라우팅된 공급자 네트워크는 스칼라빌리티 및 내결함성을 제공합니다. 예를 들어 주요 오류가 발생하면 전체 네트워크가 실패하는 대신 하나의 세그먼트만 영향을 받습니다.

    자세한 내용은 라우팅된 공급자 네트워크 배포를 참조하십시오.

  • 네트워크 리소스를 고가용성으로 설정합니다.

    가용성 영역(AZ) 및 VRRP(Virtual Router Redundancy Protocol)를 사용하여 네트워크 리소스를 고가용성으로 유지할 수 있습니다. Operator는 다른 AZ의 다른 전원에 연결된 네트워크 노드를 그룹화합니다. 다음으로 Operator는 DHCP, L3, FW 등의 중요한 서비스를 별도의 AZ에 예약합니다.

    RHOSP는 VRRP를 사용하여 프로젝트 라우터 및 유동 IP 주소를 고가용성으로 설정합니다. 중앙 집중식 라우팅 대신 DVR(Distributed Virtual Routing)은 L3 에이전트를 배포하고 모든 컴퓨팅 노드에 라우터를 예약하는 VRRP 기반의 대체 라우팅 설계를 제공합니다.

    자세한 내용은 가용성 영역을 사용하여 네트워크 리소스의 고가용성을 참조하십시오.

  • 포트 수준에서 네트워크를 보호합니다.

    보안 그룹은 포트 수준에서 Ingress(네바운드에서 인바운드) 네트워크 트래픽을 제어하는 가상 방화벽 규칙에 대한 컨테이너를 제공합니다. 보안 그룹은 기본 거부 정책을 사용하며 특정 트래픽을 허용하는 규칙만 포함합니다. 각 포트는 추가 방식으로 하나 이상의 보안 그룹을 참조할 수 있습니다. firewall 드라이버는 보안 그룹 규칙을 iptables와 같은 기본 패킷 필터링 기술의 구성으로 변환합니다.

    자세한 내용은 공유 보안 그룹 구성을 참조하십시오.

  • 포트 트래픽을 관리합니다.

    허용된 주소 쌍을 사용하여 서브넷과 관계없이 네트워크 트래픽이 포트를 통과할 수 있도록 특정 MAC 주소, IP 주소 또는 둘 다 식별합니다. 허용되는 주소 쌍을 정의할 때 빠른 데이터 플레인 페일오버를 활성화하기 위해 두 VM 인스턴스 간 IP 주소를 사용하는 VRRP(Virtual Router Redundancy Protocol)와 같은 프로토콜을 사용할 수 있습니다.

    자세한 내용은 허용되는 주소 쌍 구성을 참조하십시오.

  • 대규모 오버레이 네트워크를 최적화합니다.

    L2 채우기 드라이버를 사용하면 대규모 오버레이 네트워크에서 브로드캐스트, 멀티 캐스트 및 유니캐스트 트래픽을 활성화할 수 있습니다.

    자세한 내용은 L2 채우기 드라이버 구성을 참조하십시오.

  • VM 인스턴스의 트래픽 수신 및 송신 제한을 설정합니다.

    QoS(Quality of Service) 정책을 사용하여 송신 및 수신 트래픽에 속도 제한을 적용하여 인스턴스에 다양한 서비스 수준을 제공할 수 있습니다. 개별 포트에 QoS 정책을 적용할 수 있습니다. 특정 정책이 연결된 포트가 정책을 상속하지 않는 프로젝트 네트워크에 QoS 정책을 적용할 수도 있습니다.

    자세한 내용은 QoS (Quality of Service) 정책 구성을 참조하십시오.

  • RHOSP 프로젝트에서 생성할 수 있는 네트워크 리소스의 양을 관리합니다.

    Networking 서비스 할당량 옵션을 사용하면 프로젝트 사용자가 생성할 수 있는 네트워크 리소스의 양을 제한할 수 있습니다. 여기에는 포트, 서브넷, 네트워크 등과 같은 리소스가 포함됩니다.

    자세한 내용은 프로젝트 할당량 관리를 참조하십시오.

  • NFV(Network Functions Virtualization)에 대한 VM 인스턴스를 최적화합니다.

    인스턴스는 단일 가상 NIC를 통해 VLAN 태그된 트래픽을 전송하고 수신할 수 있습니다. 이는 VLAN 태그 지정된 트래픽을 예상하는 NFV 애플리케이션(VNF)에 특히 유용하므로 단일 가상 NIC가 여러 고객 또는 서비스를 제공할 수 있습니다.

    VLAN 투명한 네트워크에서 VM 인스턴스에 VLAN 태그를 설정합니다. VLAN 태그는 네트워크를 통해 전송되고 동일한 VLAN의 VM 인스턴스에서 사용하며 다른 인스턴스 및 장치에서 무시됩니다. VLAN 트렁크는 VLAN을 단일 트렁크 포트에 결합하여 VLAN 인식 인스턴스를 지원합니다.

    자세한 내용은 VLAN 인식 인스턴스를 참조하십시오.

  • 공유 네트워크에 인스턴스를 연결할 수 있는 프로젝트를 제어합니다.

    클라우드 관리자는 RHOSP Networking 서비스의 역할 기반 액세스 제어(RBAC) 정책을 사용하여 일부 프로젝트에서 네트워크를 생성하는 기능을 제거하고 대신 프로젝트에 해당하는 기존 네트워크에 연결할 수 있습니다.

    자세한 내용은 RBAC 정책 구성을 참조하십시오.

1.2. 네트워킹 서비스 구성 요소

RHOSP(Red Hat OpenStack Platform) 네트워킹 서비스(neutron)에는 다음 구성 요소가 포함됩니다.

  • API 서버

    RHOSP 네트워킹 API에는 계층 2 네트워킹 및 IP 주소 관리(IPAM) 지원뿐만 아니라 계층 2 네트워크 및 외부 네트워크로의 게이트웨이를 라우팅할 수 있는 계층 3 라우터 구성의 확장이 포함됩니다. RHOSP 네트워킹에는 라우터, 스위치, 가상 스위치, SDN(소프트웨어 정의 네트워킹) 컨트롤러를 비롯한 다양한 상용 및 오픈 소스 네트워크 기술과의 상호 운용성을 지원하는 플러그인 목록이 늘어나고 있습니다.

  • 모듈식 계층 2(ML2) 플러그인 및 에이전트

    ML2는 포트를 연결 및 분리하고, 네트워크 또는 서브넷을 생성하며, IP 주소를 제공합니다.

  • 메시징 대기열

    에이전트 간에 RPC 요청을 수락하고 라우팅하여 API 작업을 완료합니다. 메시지 큐는 Open vSwitch 및 Linux 브리지용 ML2 메커니즘 드라이버의 각 하이퍼바이저에서 실행되는 neutron 서버와 neutron 에이전트 간 ML2 플러그인에서 사용됩니다.

1.3. 모듈식 계층 2(ML2) 네트워킹

모듈식 계층 2(ML2)는 RHOSP(Red Hat OpenStack Platform) 네트워킹 코어 플러그인입니다. ML2 모듈식 설계를 통해 메커니즘 드라이버를 통해 혼합 네트워크 기술을 동시에 작동할 수 있습니다. OVN(Open Virtual Network)은 ML2와 함께 사용되는 기본 메커니즘 드라이버입니다.

ML2 프레임워크는 구성할 수 있는 두 가지 유형의 드라이버를 구분합니다.

유형 드라이버

RHOSP 네트워크가 기술적으로 실현되는 방법을 정의합니다.

사용 가능한 각 네트워크 유형은 ML2 유형 드라이버에 의해 관리되며 필요한 유형별 네트워크 상태를 유지합니다. 공급자 네트워크의 유형별 정보 검증, 유형 드라이버는 프로젝트 네트워크에서 사용 가능한 세그먼트 할당을 담당합니다. 유형 드라이버의 예로는 GENECDHEE, GRE, VXLAN 등이 있습니다.

메커니즘 드라이버

특정 유형의 RHOSP 네트워크에 액세스하는 메커니즘을 정의합니다.

메커니즘 드라이버는 유형 드라이버에 의해 설정된 정보를 가져와서 활성화된 네트워킹 메커니즘에 적용합니다. 메커니즘 드라이버의 예로는 OVN(Open Virtual Networking) 및 OVS(Open vSwitch)가 있습니다.

메커니즘 드라이버는 L2 에이전트를 사용하고 RPC를 사용하여 외부 장치 또는 컨트롤러와 직접 상호 작용할 수 있습니다. 여러 메커니즘을 사용하고 드라이버를 동시에 사용하여 동일한 가상 네트워크의 다른 포트에 액세스할 수 있습니다.

1.4. ML2 네트워크 유형

여러 네트워크 세그먼트를 동시에 작동할 수 있습니다. ML2는 여러 네트워크 세그먼트의 사용 및 상호 연결을 지원합니다. ML2가 포트를 연결과 분리하기 때문에 포트를 네트워크 세그먼트에 바인딩할 필요는 없습니다. 메커니즘 드라이버에 따라 ML2는 다음 네트워크 세그먼트 유형을 지원합니다.

  • flat
  • VLAN
  • GENECDHEE 터널
  • VXLAN 및 GRE 터널
flat
모든 VM(가상 머신) 인스턴스는 동일한 네트워크에 있으며 호스트와 공유할 수도 있습니다. VLAN 태그 지정 또는 기타 네트워크 분리가 발생하지 않습니다.
VLAN

RHOSP 네트워킹 사용자는 실제 네트워크에 있는 VLAN에 해당하는 VLAN ID(802.1Q 태그)를 사용하여 여러 공급자 또는 프로젝트 네트워크를 생성할 수 있습니다. 이렇게 하면 인스턴스가 환경 전반에서 서로 통신할 수 있습니다. 또한 동일한 계층 2 VLAN에서 전용 서버, 방화벽, 로드 밸런서 및 기타 네트워크 인프라와 통신할 수 있습니다.

VLAN을 사용하여 동일한 스위치에서 실행되는 컴퓨터의 네트워크 트래픽을 분할할 수 있습니다. 즉, 다른 네트워크의 멤버가 되도록 포트를 구성하여 스위치를 논리적으로 나눌 수 있습니다. 기본적으로 보안상의 이유로 트래픽을 분리하는 데 사용할 수 있는 Mini-LANs입니다.

예를 들어 스위치에 총 24개의 포트가 있는 경우 포트 1-6을 VLAN200에 할당하고 포트 7-18을 VLAN201에 할당할 수 있습니다. 결과적으로 VLAN200에 연결된 컴퓨터는 VLAN201의 컴퓨터와 완전히 분리되어 직접 통신할 수 없으며 원하는 경우 트래픽은 두 개의 개별 물리적 스위치인 것처럼 라우터를 통과해야 합니다. 방화벽은 또한 어떤 VLAN이 서로 통신할 수 있는지 제어하는 데 유용할 수 있습니다.

GENECDHEE 터널
GENECDHEE는 네트워크 가상화에서 다양한 장치의 변경 기능과 요구 사항을 인식하고 수용합니다. 전체 시스템에 대해 규정적이지 않고 터널링을 위한 프레임워크를 제공합니다. Geneve는 캡슐화 중에 추가되고 다양한 가상화 시나리오에 적응하려고 시도하는 메타데이터의 내용을 정의합니다. 이는 UDP를 전송 프로토콜로 사용하며 확장 가능한 옵션 헤더를 사용하여 크기가 동적입니다. Geneve는 유니캐스트, 멀티캐스트 및 브로드캐스트를 지원합니다. GENRuntimeConfig 유형 드라이버는 ML2/OVN 메커니즘 드라이버와 호환됩니다.
VXLAN 및 GRE 터널
VXLAN 및 GRE는 네트워크 오버레이를 사용하여 인스턴스 간 개인 통신을 지원합니다. RHOSP 네트워킹 라우터는 트래픽이 GRE 또는 VXLAN 프로젝트 네트워크 외부에서 트래버스할 수 있도록 하는 데 필요합니다. 라우터는 인터넷을 포함하여 외부 네트워크와 직접 연결된 프로젝트 네트워크를 연결해야 합니다. 라우터는 유동 IP 주소를 사용하여 외부 네트워크에서 직접 인스턴스에 연결할 수 있는 기능을 제공합니다. VXLAN 및 GRE 유형 드라이버는 ML2/OVS 메커니즘 드라이버와 호환됩니다.

1.5. 모듈식 계층 2(ML2) 메커니즘 드라이버

모듈식 계층 2(ML2) 플러그인은 공통 코드 베이스를 사용하는 메커니즘으로 구현됩니다. 이 방법을 사용하면 코드 재사용을 활성화하고 코드 유지 관리 및 테스트 관련 많은 복잡성을 제거합니다.

오케스트레이션 서비스(heat) 매개변수인 NeutronMechanismDrivers 를 사용하여 메커니즘 드라이버를 활성화합니다. 다음은 heat 사용자 지정 환경 파일의 예입니다.

parameter_defaults:
  ...
  NeutronMechanismDrivers: ansible,ovn,baremetal
  ...

메커니즘 드라이버를 지정하는 순서가 중요합니다. 이전 예에서 baremetal 메커니즘 드라이버를 사용하여 포트를 바인딩하려면 ansible 앞에 baremetal 을 지정해야 합니다. 그렇지 않으면 ansible 드라이버가 NeutronMechanismDrivers 의 값 목록에서 baremetal 보다 우선하므로 포트를 바인딩합니다.

Red Hat은 현재 대부분의 고객에게 ML2/OVS 메커니즘 드라이버를 통해 즉시 이점을 제공하기 때문에 RHOSP 15부터 새로운 모든 배포에 대해 ML2/OVN을 기본 메커니즘 드라이버로 선택했습니다. ML2/OVN 기능 세트를 지속적으로 개선하고 개선하면서 각 릴리스와 함께 곱한 이점을 얻을 수 있습니다.

RHOSP 17 릴리스를 통해 더 이상 사용되지 않는 ML2/OVS 메커니즘 드라이버에 대한 지원을 사용할 수 있습니다. 이 기간 동안 ML2/OVS 드라이버는 유지 관리 모드로 남아 버그 수정 및 정상적인 지원을 받으며 대부분의 새로운 기능 개발은 ML2/OVN 메커니즘 드라이버에서 수행됩니다.

RHOSP 18.0에서 Red Hat은 ML2/OVS 메커니즘 드라이버를 완전히 제거하고 지원을 중단할 계획입니다.

기존 RHOSP(Red Hat OpenStack Platform) 배포에서 ML2/OVS 메커니즘 드라이버를 사용하는 경우 지금 시작하여 메커니즘 드라이버로 마이그레이션할 계획을 평가하십시오. 마이그레이션은 RHOSP 16.2에서 지원되며 RHOSP 17.1에서 지원됩니다. 마이그레이션 툴은 테스트 목적으로만 RHOSP 17.0에서 사용할 수 있습니다.

Red Hat은 ML2/OVS에서 ML2/OVN으로의 마이그레이션을 시도하기 전에 사전 대응적인 지원 케이스를 제출해야 합니다. Red Hat은 사전 지원 케이스 없이 마이그레이션을 지원하지 않습니다. Red Hat OpenStack Platform에서 예정된 활동에 대한 사전 대응 사례를 어떻게 열 수 있습니까?

추가 리소스

1.6. Open vSwitch

OVS(Open vSwitch)는 Linux 소프트웨어 브릿지와 유사하게 소프트웨어 정의 네트워킹(SDN) 가상 스위치입니다. OVS는 업계 표준 OpenFlow 및 sFlow를 지원하는 가상화 네트워크에 전환 서비스를 제공합니다. OVS는 STP, LACP, 802.1Q VLAN 태그와 같은 계층 2 기능을 사용하여 물리적 스위치와도 통합할 수 있습니다. Open vSwitch 버전 1.11.0-1.el6 이상에서는 VXLAN 및 GRE를 사용한 터널링도 지원합니다.

참고

OVS에서 네트워크 루프 발생 위험을 완화하기 위해 단일 인터페이스 또는 단일 본딩만 지정된 브릿지의 멤버가 될 수 있습니다. 여러 개의 본딩이나 인터페이스가 필요한 경우 여러 브릿지를 설정할 수 있습니다.

추가 리소스

1.7. OVN(Open Virtual Network)

OVN(Open Virtual Network)은 가상 머신 및 컨테이너 환경에서 논리적 네트워크 추상화를 지원하는 시스템입니다. Open vSwitch용 오픈 소스 가상 네트워킹이라고도 하는 OVN은 OVS의 기존 기능을 보완하여 논리 L2 및 L3 오버레이, 보안 그룹 및 DHCP와 같은 서비스의 기본 지원을 추가합니다.

물리적 네트워크는 물리적 교전, 스위치 및 라우터로 구성됩니다. 가상 네트워크는 물리적 네트워크를 하이퍼바이저 또는 컨테이너 플랫폼으로 확장하여 VM 또는 컨테이너를 물리적 네트워크에 연결합니다. OVN 논리 네트워크는 터널 또는 기타 캡슐화에 의해 물리적 네트워크에서 제한되는 소프트웨어로 구현된 네트워크입니다. 이를 통해 논리 네트워크에 사용된 IP 및 기타 주소 공간이 충돌 없이 물리적 네트워크에서 사용되는 주소와 중복될 수 있습니다. 논리적 네트워크 토폴로지는 해당 네트워크가 실행되는 물리적 네트워크의 토폴로지에 관계없이 정렬될 수 있습니다. 따라서 논리적 네트워크의 일부인 VM은 네트워크 중단 없이 하나의 물리적 시스템에서 다른 물리적 시스템으로 마이그레이션할 수 있습니다.

캡슐화 계층을 사용하면 논리 네트워크에 연결된 VM 및 컨테이너가 물리적 네트워크의 노드와 통신할 수 없습니다. VM 및 컨테이너 클러스터링의 경우 이는 허용되거나 짝수일 수 있지만 대부분의 경우 VM과 컨테이너는 물리적 네트워크에 연결해야 합니다. OVN은 이러한 목적으로 여러 유형의 게이트웨이를 제공합니다. OVN 배포는 다음과 같은 여러 구성 요소로 구성됩니다.

클라우드 관리 시스템 (CMS)
OVN 논리 네트워크 요소를 관리하고 OVN 논리 네트워크 인프라를 물리적 네트워크 요소에 연결하여 OVN을 물리적 네트워크에 통합합니다. 몇 가지 예로는 OpenStack 및 OpenShift가 있습니다.
OVN 데이터베이스
OVN 논리 및 물리적 네트워크를 나타내는 데이터를 저장합니다.
Hypervisors
Open vSwitch를 실행하고 OVN 논리 네트워크를 물리적 또는 가상 시스템의 OpenFlow로 변환합니다.
게이트웨이
터널과 물리적 네트워크 인프라 간에 패킷을 전달하여 터널 기반 OVN 논리 네트워크를 물리적 네트워크로 확장합니다.

1.8. 모듈식 계층 2(ML2) 유형 및 메커니즘 드라이버 호환성

RHOSP(Red Hat OpenStack Platform) 데이터 네트워크를 계획할 때 각 ML2 메커니즘 드라이버에서 지원하는 네트워크 유형을 확인하려면 다음 표를 참조하십시오.

표 1.1. ML2 메커니즘 드라이버에서 지원하는 네트워크 유형

메커니즘 드라이버

이러한 유형의 드라이버 지원

flat

GRE

VLAN

VXLAN

GENEVE

OVN(Open Virtual Network)

제공됨

없음

제공됨

예 [1]

제공됨

OVS(Open vSwitch)

제공됨

제공됨

제공됨

제공됨

없음

[1] ML2/OVN VXLAN 지원은 네트워크당 4096개의 네트워크와 4096개의 포트로 제한됩니다. 또한 수신 포트가 전달되지 않으므로 수신 포트를 사용하는 ACL은 ML2/OVN 및 VXLAN에서 작동하지 않습니다.

1.9. RHOSP 네트워킹 서비스용 확장 드라이버

RHOSP(Red Hat OpenStack Platform) 네트워킹 서비스(neutron)는 확장 가능합니다. 확장 기능은 두 가지 용도를 제공합니다. 즉, 버전 변경이 필요 없이 API에 새로운 기능을 도입할 수 있으며 벤더별 니치 기능을 도입할 수 있습니다. 애플리케이션은 /extensions URI에서 GET을 수행하여 사용 가능한 확장을 프로그래밍 방식으로 나열할 수 있습니다. 이는 버전이 지정된 요청입니다. 즉, 한 API 버전에서 사용할 수 있는 확장은 다른 API 버전에서 제공되지 않을 수 있습니다.

ML2 플러그인은 다른 플러그인 드라이버를 통해 네트워크 오브젝트용 ML2 플러그인에 구현된 코어 리소스를 확장할 수 있는 확장 드라이버도 지원합니다. 확장 드라이버의 예로는 QoS, 포트 보안 등이 포함됩니다.

2장. ML2/OVN으로 작업

RHOSP(Red Hat OpenStack Platform) 네트워크는 네트워킹 서비스(neutron)에 의해 관리됩니다. Networking 서비스의 코어는 Modular Layer 2(ML2) 플러그인이며 RHOSP ML2 플러그인의 기본 메커니즘 드라이버는 OVN(Open Virtual Networking) 메커니즘 드라이버입니다.

이전 RHOSP 버전은 기본적으로 OVS(Open vSwitch) 메커니즘 드라이버를 사용하지만 Red Hat은 대부분의 배포에 ML2/OVN 메커니즘 드라이버를 권장합니다.

2.1. RHOSP OVN 아키텍처의 구성 요소 목록

RHOSP OVN 아키텍처는 Networking API를 지원하기 위해 OVS Modular Layer 2(ML2) 메커니즘 드라이버를 OVN ML2 메커니즘 드라이버로 교체합니다. OVN은 Red Hat OpenStack 플랫폼을 위한 네트워킹 서비스를 제공합니다.

figure 2.1에 설명된 대로 OVN 아키텍처는 다음 구성 요소 및 서비스로 구성됩니다.

OVN 메커니즘 드라이버를 사용하는 ML2 플러그인
ML2 플러그인은 OpenStack 관련 네트워킹 구성을 플랫폼 중립 OVN 논리 네트워킹 구성으로 변환합니다. 일반적으로 컨트롤러 노드에서 실행됩니다.
OVN northbound(NB) 데이터베이스(ovn-nb)
이 데이터베이스는 OVN ML2 플러그인의 논리 OVN 네트워킹 구성을 저장합니다. 일반적으로 컨트롤러 노드에서 실행되며 TCP 포트 6641 에서 수신 대기합니다.
OVN northbound 서비스(ovn-northd)
이 서비스는 논리 네트워킹 구성을 OVN NB 데이터베이스에서 논리 데이터 경로 흐름으로 변환하고 OVN Southbound 데이터베이스에서 이러한 구성을 채웁니다. 일반적으로 컨트롤러 노드에서 실행됩니다.
OVN southbound(SB) 데이터베이스(ovn-sb)
이 데이터베이스는 변환된 논리 데이터 경로 흐름을 저장합니다. 일반적으로 컨트롤러 노드에서 실행되며 TCP 포트 6642 에서 수신 대기합니다.
OVN 컨트롤러 (ovn-controller)
이 컨트롤러는 OVN SB 데이터베이스에 연결하고 네트워크 트래픽을 제어하고 모니터링하기 위해 Open vSwitch 컨트롤러 역할을 합니다. OS::Tripleo::Services::OVNController 가 정의된 모든 컴퓨팅 및 게이트웨이 노드에서 실행됩니다.
OVN 메타데이터 에이전트(ovn-metadata-agent)
이 에이전트는 메타데이터 API 요청을 프록시하는 데 사용되는 OVS 인터페이스, 네트워크 네임스페이스 및 HAProxy 프로세스를 관리하기 위한 haproxy 인스턴스를 생성합니다. 에이전트는 OS::TripleO::Services::OVNMetadataAgent 가 정의된 모든 컴퓨팅 및 게이트웨이 노드에서 실행됩니다.
OVS 데이터베이스 서버(OVSDB)
OVN Northbound 및 Southbound 데이터베이스를 호스팅합니다. ovs-vswitchd 와 상호 작용하여 OVS 데이터베이스 conf.db 를 호스팅합니다.
참고

NB 데이터베이스의 스키마 파일은 /usr/share/ovn/ovn-nb.ovsschema 에 있으며 SB 데이터베이스 스키마 파일은 /usr/share/ovn/ovn-sb.ovsschema 에 있습니다.

그림 2.1. RHOSP 환경의 OVN 아키텍처

329 OpenStack OVN Architecture 0623 1

2.2. ML2/OVN 데이터베이스

Red Hat OpenStack Platform ML2/OVN 배포에서는 공유 분산 데이터베이스를 통해 프로세스 간에 네트워크 구성 정보가 전달됩니다. 이러한 데이터베이스를 검사하여 네트워크 상태를 확인하고 문제를 확인할 수 있습니다.

OVN northbound 데이터베이스

northbound 데이터베이스(OVN_Northbound)는 OVN과 RHOSP(Red Hat OpenStack Platform)와 같은 클라우드 관리 시스템 간의 인터페이스 역할을 합니다. RHOSP는 northbound 데이터베이스의 콘텐츠를 생성합니다.

northbound 데이터베이스에는 논리 포트, 논리 스위치, 논리 라우터 등의 컬렉션으로 제공되는 현재 원하는 네트워크의 상태가 포함되어 있습니다. 모든 RHOSP Networking 서비스(neutron) 오브젝트는 northbound 데이터베이스의 테이블에 표시됩니다.

OVN southbound 데이터베이스
southbound 데이터베이스(OVN_Southbound)는 가상 네트워크 추상화를 지원하기 위해 OVN 시스템의 논리 및 물리적 구성 상태를 보유하고 있습니다. ovn-controller 는 이 데이터베이스의 정보를 사용하여 Networking 서비스(neutron) 요구 사항을 충족하도록 OVS를 구성합니다.

2.3. 컴퓨팅 노드의 ovn-controller 서비스

ovn-controller 서비스는 각 컴퓨팅 노드에서 실행되며 OVN southbound(SB) 데이터베이스 서버에 연결하여 논리 흐름을 검색합니다. ovn-controller 는 이러한 논리 흐름을 물리적 OpenFlow 흐름으로 변환하고 해당 흐름을 OVS 브리지(br-int)에 추가합니다.

ovs-vswitchd 와 통신하고 OpenFlow 흐름을 설치하기 위해 ovn-controllerovn-controller 가 시작될 때 전달된 UNIX 소켓 경로를 사용하여 활성 ovs db-server 서버(예: unix:/var/run/openvswitch/db.sock) 중 하나에 연결됩니다.

ovn-controller 서비스는 Open_vSwitch 테이블의 external_ids 열에 있는 특정 키-값 쌍을 예상합니다. puppet-ovnpuppet-vswitch 를 사용하여 이러한 필드를 채웁니다. 다음 예제에서는 puppet-vswitchexternal_ids 열에서 구성하는 키-값 쌍을 보여줍니다.

hostname=<HOST NAME>
ovn-encap-ip=<IP OF THE NODE>
ovn-encap-type=geneve
ovn-remote=tcp:OVN_DBS_VIP:6642

2.4. 컴퓨팅 노드의 OVN 메타데이터 에이전트

OVN 메타데이터 에이전트는 tripleo-heat-templates/deployment/ovn-metadata-container-puppet.yaml 파일에 구성되어 있으며 OS::TripleO::Services::OVNMetadataAgent 를 통해 기본 Compute 역할에 포함됩니다. 따라서 기본 매개 변수가 있는 OVN 메타데이터 에이전트는 OVN 배포의 일부로 배포됩니다.

OpenStack 게스트 인스턴스는 링크-로컬 IP 주소에서 사용 가능한 네트워킹 메타데이터 서비스에 액세스합니다. 169.254.169.254. neutron-ovn-metadata-agent 는 Compute 메타데이터 API가 있는 호스트 네트워크에 액세스할 수 있습니다. 각 HAProxy는 적절한 호스트 네트워크에 연결할 수 없는 네트워크 네임스페이스에 있습니다. HAProxy는 필요한 헤더를 메타데이터 API 요청에 추가한 다음 UNIX 도메인 소켓을 통해 요청을 neutron-ovn-metadata-agent 로 전달합니다.

OVN Networking 서비스는 메타데이터 서비스를 활성화하는 각 가상 네트워크에 대해 고유한 네트워크 네임스페이스를 생성합니다. 컴퓨팅 노드의 인스턴스에서 액세스하는 각 네트워크에는 해당 메타데이터 네임스페이스(ovnmeta-<network_uuid>)가 있습니다.

2.5. OVN 구성 가능 서비스

Red Hat OpenStack Platform은 일반적으로 컨트롤러 역할, 컴퓨팅 역할 및 다양한 스토리지 역할 유형의 노드와 같이 사전 정의된 역할의 노드로 구성됩니다. 이러한 각 기본 역할에는 코어 heat 템플릿 컬렉션에 정의된 서비스 세트가 포함되어 있습니다.

기본 RHOSP(Red Hat OpenStack) 배포에서는 ML2/OVN 구성 가능 서비스인 ovn-dbs가 컨트롤러 노드에서 실행됩니다. 서비스는 구성 가능이므로 Networker 역할과 같은 다른 역할에 할당할 수 있습니다. ML2/OVN 서비스를 다른 역할에 할당하려면 컨트롤러 노드의 부하를 줄이고 Networker 노드에서 Networking 서비스를 격리하여 고가용성 전략을 구현할 수 있습니다.

2.6. OVN을 사용한 계층 3 고가용성

OVN은 특별한 구성없이 3 계층 고가용성(L3 HA)을 지원합니다. OVN은 지정된 외부 네트워크에서 L3 게이트웨이 역할을 할 수 있는 사용 가능한 모든 게이트웨이 노드에 라우터 포트를 자동으로 예약합니다. OVN L3 HA는 OVN Logical_Router_Port 테이블에 gateway_chassis 열을 사용합니다. 대부분의 기능은 번들 active_passive 출력이 있는 OpenFlow 규칙에 의해 관리됩니다. ovn-controller 는 Address Resolution Protocol(ARP) 응답기 및 라우터 활성화 및 비활성화를 처리합니다. FIP 및 라우터 외부 주소에 대한 무차별 ARP도 ovn-controller 에 의해 정기적으로 전송됩니다.

참고

L3HA는 OVN을 사용하여 노드의 병목 현상이 발생하지 않도록 원래 게이트웨이 노드로 라우터의 균형을 다시 조정합니다.

BFD 모니터링

OVN은 BFD( Bidirectional Forwarding Detection) 프로토콜을 사용하여 게이트웨이 노드의 가용성을 모니터링합니다. 이 프로토콜은 노드에서 노드로 설정된 Geneve 터널 상단에 캡슐화됩니다.

각 게이트웨이 노드는 배포의 별 토폴로지에 있는 다른 모든 게이트웨이 노드를 모니터링합니다. 게이트웨이 노드는 또한 컴퓨팅 노드를 모니터링하여 게이트웨이가 패킷 및 ARP 응답 및 알림의 라우팅을 활성화 및 비활성화할 수 있도록 합니다.

각 컴퓨팅 노드는 BFD를 사용하여 각 게이트웨이 노드를 모니터링하고 지정된 라우터의 활성 게이트웨이 노드를 통해 SNAT 및 DNAT(소스 및 대상 네트워크 주소 변환)와 같은 외부 트래픽을 자동으로 처리합니다. 컴퓨팅 노드는 다른 컴퓨팅 노드를 모니터링할 필요가 없습니다.

참고

ML2-OVS 구성에서 발생하는 외부 네트워크 오류는 탐지되지 않습니다.

OVN의 L3 HA는 다음과 같은 오류 모드를 지원합니다.

  • 게이트웨이 노드가 네트워크(tunneling 인터페이스)에서 연결이 끊어집니다.
  • OVS-vswitchd 중지 (ovs-switchd 는 BFD 신호 처리)
  • OVN-controller 가 중지됩니다(ovn-controller 가 등록된 노드로 제거됨).
참고

이 BFD 모니터링 메커니즘은 라우팅 실패가 아닌 링크 실패에서만 작동합니다.

2.7. ML2/OVN으로 사용자 정의 역할 배포

기본 RHOSP(Red Hat OpenStack) 배포에서 ML2/OVN 구성 가능 서비스는 컨트롤러 노드에서 실행됩니다. 다음 예에 설명된 것과 같이 지원되는 사용자 지정 역할을 선택적으로 사용할 수 있습니다.

Networker
전용 네트워크 노드에서 OVN 구성 가능 서비스를 실행합니다.
SR-IOV를 사용하는 Networker
SR-IOV를 사용하여 전용 네트워크 노드에서 OVN 구성 가능 서비스를 실행합니다.
SR-IOV가 있는 컨트롤러
SR-IOV 가능 컨트롤러 노드에서 OVN 구성 가능 서비스를 실행합니다.

사용자 지정 역할을 생성할 수도 있습니다.

제한

다음 제한 사항은 이번 릴리스에서 ML2/OVN 및 기본 OVN DHCP와 함께 SR-IOV 사용에 적용됩니다.

  • 모든 외부 포트는 모든 포트에 대해 하나의 HA 섀시 그룹만 있으므로 단일 게이트웨이 노드에 예약됩니다.
  • VLAN 테넌트 네트워크의 VF(direct) 포트의 North/south 라우팅은 논리 라우터의 게이트웨이 포트와 함께 배치되지 않기 때문에 SR-IOV에서 작동하지 않습니다. https://bugs.launchpad.net/neutron/+bug/1875852 을 참조하십시오.

사전 요구 사항

절차

  1. 언더클라우드 호스트에 stack 사용자로 로그인하고 stackrc 파일을 소싱합니다.

    $ source stackrc
  2. 배포에 적합한 사용자 지정 역할 파일을 선택합니다. 필요에 따라 배포 명령에 직접 사용합니다. 또는 다른 사용자 지정 역할 파일을 결합하는 사용자 지정 역할 파일을 생성할 수 있습니다.

    DeploymentRole역할 파일

    Networker 역할

    Networker

    Networker.yaml

    SR-IOV를 사용하는 Networker 역할

    NetworkerSriov

    NetworkerSriov.yaml

    SR-IOV를 사용한 공동 배치 제어 및 네트워크 관리자

    ControllerSriov

    ControllerSriov.yaml

  3. (선택 사항) 이전에 나열된 사용자 지정 역할 파일 중 하나를 다른 사용자 지정 역할 파일과 결합하는 새 사용자 지정 역할 데이터 파일을 생성합니다.

    Director 설치 및 사용 가이드의 roles_data 파일 생성에 있는 지침을 따르십시오. 배포에 따라 적절한 소스 역할 파일을 포함합니다.

  4. (선택 사항) 역할의 특정 노드를 식별하려면 특정 하드웨어 플레이버를 생성하고 특정 노드에 플레이버를 할당할 수 있습니다. 그런 다음 환경 파일을 사용하여 역할의 플레이버를 정의하고 노드 수를 지정합니다.

    자세한 내용은 Director 설치 및 사용 가이드에서 새 역할 생성 예제를 참조하십시오.

  5. 배포에 적절하게 환경 파일을 생성합니다.

    Deployment환경 파일 샘플

    Networker 역할

    neutron-ovn-dvr-ha.yaml

    SR-IOV를 사용하는 Networker 역할

    ovn-sriov.yaml

  6. 배포에 따라 다음 설정을 포함합니다.

    Deployment설정

    Networker 역할

    ControllerParameters:
        OVNCMSOptions: ""
    ControllerSriovParameters:
            OVNCMSOptions: ""
    NetworkerParameters:
        OVNCMSOptions: "enable-chassis-as-gw"
    NetworkerSriovParameters:
        OVNCMSOptions: ""

    SR-IOV를 사용하는 Networker 역할

    OS::TripleO::Services::NeutronDhcpAgent: OS::Heat::None
    
    ControllerParameters:
        OVNCMSOptions: ""
    ControllerSriovParameters:
            OVNCMSOptions: ""
    NetworkerParameters:
        OVNCMSOptions: ""
    NetworkerSriYou can uovParameters:
        OVNCMSOptions: "enable-chassis-as-gw"

    SR-IOV를 사용한 공동 배치 제어 및 네트워크 관리자

    OS::TripleO::Services::NeutronDhcpAgent: OS::Heat::None
    
    ControllerParameters:
        OVNCMSOptions: ""
    ControllerSriovParameters:
            OVNCMSOptions: "enable-chassis-as-gw"
    NetworkerParameters:
        OVNCMSOptions: ""
    NetworkerSriovParameters:
        OVNCMSOptions: ""
  7. 배포 명령을 실행하고 코어 heat 템플릿, 기타 환경 파일 및 -r 옵션을 사용하여 배포 명령에 사용자 지정 역할 데이터 파일을 포함합니다.

    중요

    후속 환경 파일에 정의된 매개 변수와 리소스가 우선하므로 환경 파일의 순서가 중요합니다.

    예제

    $ openstack overcloud deploy --templates <core_heat_templates> \
    -e <other_environment_files> \
    -e /home/stack/templates/my-neutron-environment.yaml
    -r mycustom_roles_file.yaml

검증 단계

  1. Controller 또는 Networker 노드에 tripleo-admin 사용자로 로그인합니다.

    예제

    ssh tripleo-admin@controller-0

  2. ovn_metadata_agent 가 실행 중인지 확인합니다.

    $ sudo podman ps | grep ovn_metadata

    샘플 출력

    a65125d9588d  undercloud-0.ctlplane.localdomain:8787/rh-osbs ...
    openstack-neutron-metadata-agent-ovn ...
    kolla_start  23 hours ago  Up 21 hours ago  ovn_metadata_agent

  3. OVN 서비스 또는 전용 네트워크 노드가 있는 컨트롤러 노드가 OVS의 게이트웨이로 구성되었는지 확인합니다.

    $ sudo ovs-vsctl get Open_Vswitch . external_ids:ovn-cms-options

    샘플 출력

    enable-chassis-as-gw

SR-IOV 배포의 추가 확인 단계

  1. 컴퓨팅 노드에 tripleo-admin 사용자로 로그인합니다.

    예제

    ssh tripleo-admin@compute-0

  2. neutron_sriov_agent 가 컴퓨팅 노드에서 실행 중인지 확인합니다.

    sudo podman ps | grep neutron_sriov_agent

    샘플 출력

    f54cbbf4523a  undercloud-0.ctlplane.localdomain:8787 ...
    openstack-neutron-sriov-agent ...
    kolla_start  23 hours ago  Up 21 hours ago  neutron_sriov_agent

  3. 네트워크 사용 가능 SR-IOV NIC가 성공적으로 탐지되었는지 확인합니다.

    $ sudo podman exec -uroot galera-bundle-podman-0 mysql nova \
    -e 'select hypervisor_hostname,pci_stats from compute_nodes;'

    샘플 출력

    computesriov-1.localdomain	{... {"dev_type": "type-PF", "physical_network"
    : "datacentre", "trusted": "true"}, "count": 1}, ... {"dev_type": "type-VF",
    "physical_network": "datacentre", "trusted": "true", "parent_ifname":
    "enp7s0f3"}, "count": 5}, ...}
    
    computesriov-0.localdomain	{... {"dev_type": "type-PF", "physical_network":
    "datacentre", "trusted": "true"}, "count": 1}, ... {"dev_type": "type-VF",
    "physical_network": "datacentre", "trusted": "true", "parent_ifname":
    "enp7s0f3"}, "count": 5}, ...}

추가 리소스

2.8. ML2/OVN 및 기본 OVN DHCP를 사용하는 SR-IOV

기본 OVN DHCP를 사용하여 ML2/OVN 배포에서 SR-IOV를 사용하도록 사용자 지정 역할을 배포할 수 있습니다. 2.7절. “ML2/OVN으로 사용자 정의 역할 배포”을 참조하십시오.

제한

다음 제한 사항은 이번 릴리스에서 ML2/OVN 및 기본 OVN DHCP와 함께 SR-IOV 사용에 적용됩니다.

  • 모든 외부 포트는 모든 포트에 대해 하나의 HA 섀시 그룹만 있으므로 단일 게이트웨이 노드에 예약됩니다.
  • VLAN 테넌트 네트워크의 VF(direct) 포트의 North/south 라우팅은 논리 라우터의 게이트웨이 포트와 함께 배치되지 않기 때문에 SR-IOV에서 작동하지 않습니다. https://bugs.launchpad.net/neutron/+bug/1875852 을 참조하십시오.

추가 리소스

3장. 프로젝트 네트워크 관리

프로젝트 네트워크를 사용하면 클라우드 컴퓨팅을 위한 네트워크 트래픽을 분리할 수 있습니다. 프로젝트 네트워크를 생성하는 단계에는 네트워크 계획 및 생성, 서브넷 및 라우터 추가가 포함됩니다.

3.1. VLAN 계획

Red Hat OpenStack Platform 배포를 계획할 때 개별 IP 주소를 할당하는 여러 서브넷으로 시작합니다. 여러 서브넷을 사용하는 경우 시스템 간 트래픽을 VLAN으로 분리할 수 있습니다.

예를 들어 관리 또는 API 트래픽이 웹 트래픽을 제공하는 시스템과 동일한 네트워크에 있지 않은 것이 이상적입니다. VLAN 간 트래픽은 트래픽 흐름을 관리하기 위해 방화벽을 구현할 수 있는 라우터를 통해 이동합니다.

배포의 다양한 유형의 가상 네트워킹 리소스에 대한 트래픽 격리, 고가용성 및 IP 주소 사용률을 포함하는 전체 계획의 일부로 VLAN을 계획해야 합니다.

참고

단일 네트워크의 최대 VLAN 수 또는 네트워크 노드의 하나의 OVS 에이전트에 있는 최대 VLAN 수는 4094입니다. 최대 VLAN 수가 필요한 경우 네트워크당 하나씩 여러 개의 공급자 네트워크(VXLAN 네트워크) 및 여러 네트워크 노드를 생성할 수 있습니다. 각 노드는 최대 4094개의 사설 네트워크를 포함할 수 있습니다.

3.2. 네트워크 트래픽 유형

호스트하려는 다양한 네트워크 트래픽 유형에 대해 별도의 VLAN을 할당할 수 있습니다. 예를 들어 이러한 네트워크 유형 각각에 대해 별도의 VLAN이 있을 수 있습니다. 외부 네트워크만 외부 물리적 네트워크로 라우팅할 수 있어야 합니다. 이번 릴리스에서는 director가 DHCP 서비스를 제공합니다.

참고

모든 OpenStack 배포에 이 섹션의 분리된 VLAN이 모두 필요하지는 않습니다. 예를 들어 클라우드 사용자가 필요에 따라 애드혹 가상 네트워크를 생성하지 않으면 프로젝트 네트워크가 필요하지 않을 수 있습니다. 각 VM이 다른 물리적 시스템과 동일한 스위치에 직접 연결하도록 하려면 컴퓨팅 노드를 공급자 네트워크에 직접 연결하고 해당 공급자 네트워크를 사용하도록 인스턴스를 구성합니다.

  • 프로비저닝 네트워크 - 이 VLAN은 PXE 부팅을 통해 director를 사용하여 새 노드를 배포하는 데 사용됩니다. OpenStack Orchestration(heat)은 OpenStack을 오버클라우드 베어 메탈 서버에 설치합니다. 이러한 서버는 물리적 네트워크에 연결되어 언더클라우드 인프라에서 플랫폼 설치 이미지를 수신합니다.
  • 내부 API 네트워크 - OpenStack 서비스는 API 통신, RPC 메시지 및 데이터베이스 통신을 포함한 통신을 위해 내부 API 네트워크를 사용합니다. 또한 이 네트워크는 컨트롤러 노드 간의 작동 메시지에 사용됩니다. IP 주소 할당을 계획할 때 각 API 서비스에는 자체 IP 주소가 필요합니다. 특히 다음 서비스 각각에 대해 IP 주소를 계획해야 합니다.

    • vip-msg (ampq)
    • vip-keystone-int
    • VIP-glance-int
    • vip-cinder-int
    • vip-nova-int
    • vip-neutron-int
    • vip-horizon-int
    • vip-heat-int
    • vip-ceilometer-int
    • vip-swift-int
    • vip-keystone-pub
    • vip-glance-pub
    • vip-cinder-pub
    • vip-nova-pub
    • vip-neutron-pub
    • vip-horizon-pub
    • vip-heat-pub
    • vip-ceilometer-pub
    • vip-swift-pub
참고

High Availability를 사용하는 경우 Pacemaker는 VIP 주소를 물리 노드 간에 이동합니다.

  • 스토리지 - 블록 스토리지, NFS, iSCSI 및 기타 스토리지 서비스. 성능상의 이유로 이 네트워크를 분리하여 물리적 이더넷 링크를 분리합니다.
  • Storage Management - OpenStack Object Storage(swift)는 이 네트워크를 사용하여 참여하는 복제본 노드 간에 데이터 오브젝트를 동기화합니다. 프록시 서비스는 사용자 요청과 기본 스토리지 계층 간의 중간 인터페이스 역할을 합니다. 프록시는 들어오는 요청을 수신하고 요청된 데이터를 검색하는 데 필요한 복제본을 찾습니다. Ceph 백엔드를 사용하는 서비스는 Ceph와 직접 상호 작용하지 않고 프런트 엔드 서비스를 사용하므로 스토리지 관리 네트워크를 통해 연결됩니다. RBD 드라이버는 예외이며 이 트래픽은 Ceph에 직접 연결됩니다.
  • 프로젝트 네트워크 - Neutron은 VLAN 분리(각 프로젝트 네트워크가 네트워크 VLAN임)를 사용하거나 VXLAN 또는 GRE를 사용한 터널링을 사용하여 각 프로젝트에 자체 네트워크를 제공합니다. 네트워크 트래픽은 각 프로젝트 네트워크 내에서 격리됩니다. 각 프로젝트 네트워크에는 IP 서브넷이 연결되어 있으며 여러 프로젝트 네트워크가 동일한 주소를 사용할 수 있습니다.
  • external - 외부 네트워크는 공용 API 엔드포인트와 대시보드에 대한 연결을 호스팅합니다(horizon). 이 네트워크를 SNAT에도 사용할 수 있습니다. 프로덕션 배포에서는 유동 IP 주소 및 NAT에 별도의 네트워크를 사용하는 것이 일반적입니다.
  • 공급자 네트워크 - 공급자 네트워크를 사용하여 기존 네트워크 인프라에 인스턴스를 연결합니다. 플랫 네트워킹 또는 VLAN 태그를 사용하여 공급자 네트워크를 사용하여 데이터 센터의 기존 실제 네트워크에 직접 매핑할 수 있습니다. 이를 통해 인스턴스는 OpenStack Networking 인프라 외부에 있는 시스템과 동일한 layer-2 네트워크를 공유할 수 있습니다.

3.3. IP 주소 사용

다음 시스템은 할당된 범위에서 IP 주소를 사용합니다.

  • 물리적 노드 - 각 물리적 NIC에는 하나의 IP 주소가 필요합니다. 물리적 NIC를 특정 기능에 적용하는 것이 일반적입니다. 예를 들어 중복을 위해 여러 NIC가 서로 다른 스위치에 연결된 경우 관리 및 NFS 트래픽을 별도의 물리적 NIC에 할당합니다.
  • 고가용성의 VIP(가상 IP) - 컨트롤러 노드가 공유하는 각 네트워크에 대해 1~3개의 VIP를 할당할 계획입니다.

3.4. 가상 네트워킹

다음 가상 리소스는 OpenStack Networking에서 IP 주소를 사용합니다. 이러한 리소스는 클라우드 인프라에 로컬로 간주되며 외부 물리적 네트워크의 시스템에서 연결할 수 없습니다.

  • 프로젝트 네트워크 - 각 프로젝트 네트워크에는 인스턴스에 IP 주소를 할당하는 데 사용할 수 있는 서브넷이 필요합니다.
  • 가상 라우터 - 서브넷에 연결하는 각 라우터 인터페이스에는 하나의 IP 주소가 필요합니다. DHCP를 사용하려면 각 라우터 인터페이스에 두 개의 IP 주소가 필요합니다.
  • 인스턴스 - 각 인스턴스에는 인스턴스를 호스팅하는 프로젝트 서브넷의 주소가 필요합니다. 수신 트래픽이 필요한 경우 지정된 외부 네트워크에서 인스턴스에 유동 IP 주소를 할당해야 합니다.
  • 관리 트래픽 - OpenStack 서비스 및 API 트래픽이 포함됩니다. 모든 서비스는 소수의 VIP를 공유합니다. API, RPC 및 데이터베이스 서비스는 내부 API VIP에서 통신합니다.

3.5. 네트워크 라우팅 추가

새 네트워크에서 트래픽을 라우팅할 수 있도록 하려면 기존 가상 라우터에 해당 서브넷을 인터페이스로 추가해야 합니다.

  1. 대시보드에서 Project > Network >라우터 를 선택합니다.
  2. 라우터 목록에서 가상 라우터 이름을 선택하고 Add Interface 를 클릭합니다.

    Subnet 목록에서 새 서브넷의 이름을 선택합니다. 선택적으로 이 필드에 인터페이스의 IP 주소를 지정할 수 있습니다.

  3. 인터페이스 추가를 클릭합니다.

    네트워크의 인스턴스는 서브넷 외부의 시스템과 통신할 수 있습니다.

3.6. 네트워크 계획 예

이 예에서는 여러 서브넷을 수용하는 여러 네트워크를 보여줍니다. 각 서브넷에는 다양한 IP 주소가 할당됩니다.

표 3.1. 서브넷 계획의 예

서브넷 이름주소 범위주소 수subnet mask

프로비저닝 네트워크

192.168.100.1 - 192.168.100.250

250

255.255.255.0

내부 API 네트워크

172.16.1.10 - 172.16.1.250

241

255.255.255.0

스토리지

172.16.2.10 - 172.16.2.250

241

255.255.255.0

스토리지 관리

172.16.3.10 - 172.16.3.250

241

255.255.255.0

테넌트 네트워크(GRE/VXLAN)

172.16.4.10 - 172.16.4.250

241

255.255.255.0

외부 네트워크(유동 IP)

10.1.2.10 - 10.1.3.222

469

255.255.254.0

공급자 네트워크(인프라)

10.10.3.10 - 10.10.3.250

241

255.255.252.0

3.7. 네트워크 생성

인스턴스가 서로 통신하고 DHCP를 사용하여 IP 주소를 수신할 수 있도록 네트워크를 생성합니다. 외부 네트워크 연결에 대한 자세한 내용은 물리적 네트워크 브리징을 참조하십시오.

네트워크를 생성할 때 네트워크가 여러 서브넷을 호스팅할 수 있음을 알고 있어야 합니다. 이 기능은 동일한 네트워크에서 서로 다른 시스템을 호스팅하고 이러한 시스템을 격리하는 방법을 선호하려는 경우에 유용합니다. 예를 들어 데이터베이스 트래픽이 다른 서브넷으로 이동하는 동안 웹 서버 트래픽만 하나의 서브넷에 있다고 지정할 수 있습니다. 서브넷은 서로 격리되며 다른 서브넷과 통신하려는 모든 인스턴스에 해당 트래픽이 라우터에서 전달해야 합니다. 라우팅이 필요하지 않도록 동일한 서브넷에 대량의 트래픽이 필요한 시스템을 배치하여 라우팅이 필요하지 않으므로 후속 대기 시간 및 로드를 방지할 수 있습니다.

  1. 대시보드에서 Project > Network > Networks 를 선택합니다.
  2. +Create Network 를 클릭하고 다음 값을 지정합니다.

    필드설명

    네트워크 이름

    네트워크에서 수행할 역할에 따라 설명적인 이름입니다. 네트워크를 외부 VLAN과 통합하는 경우 이름에 VLAN ID 번호를 추가하는 것이 좋습니다. 예를 들어 이 서브넷에서 HTTP 웹 서버를 호스팅하고 있는 경우, VLAN 태그는 122 입니다. 또는 네트워크 트래픽을 비공개로 유지하고 네트워크를 외부 네트워크와 통합하지 않으려는 경우 내부 전용 으로 사용할 수 있습니다.

    관리자 상태

    네트워크를 즉시 사용할 수 있는지 여부를 제어합니다. 이 필드를 사용하여 네트워크를 논리적으로 존재하지만 비활성 상태인 Down 상태로 만듭니다. 이 기능은 네트워크를 프로덕션에 즉시 입력하지 않으려는 경우에 유용합니다.

    서브넷 만들기

    서브넷을 만들지 여부를 결정합니다. 예를 들어 이 네트워크를 네트워크 연결 없이 자리 표시자로 유지하려는 경우 서브넷을 만들지 않을 수 있습니다.

  3. Next 버튼을 클릭하고 Subnet 탭에서 다음 값을 지정합니다.

    필드설명

    서브넷 이름

    서브넷의 설명이 포함된 이름을 입력합니다.

    네트워크 주소

    IP 주소 범위 및 서브넷 마스크를 하나의 값에 포함하는 CIDR 형식으로 주소를 입력합니다. 주소를 확인하려면 서브넷 마스크에 마스킹된 비트 수를 계산하고 해당 값을 IP 주소 범위에 추가합니다. 예를 들어 서브넷 마스크 255.255.255.0에는 마스크된 비트가 24개 있습니다. IPv4 주소 범위 192.168.122.0과 함께 이 마스크를 사용하려면 주소 192.168.122.0/24를 지정합니다.

    IP 버전

    유효한 유형이 IPv4 또는 IPv6인 인터넷 프로토콜 버전을 지정합니다. Network Address(네트워크 주소) 필드의 IP 주소 범위는 선택한 버전과 일치해야 합니다.

    게이트웨이 IP

    기본 게이트웨이에 대한 라우터 인터페이스의 IP 주소입니다. 이 주소는 외부 위치로 향하는 트래픽을 라우팅하기 위한 다음 홉이며, 네트워크 주소 필드에 지정하는 범위 내에 있어야 합니다. 예를 들어 CIDR 네트워크 주소가 192.168.122.0/24인 경우 기본 게이트웨이는 192.168.122.1일 수 있습니다.

    게이트웨이 비활성화

    전달을 비활성화하고 서브넷을 격리합니다.

  4. 다음을 클릭하여 DHCP 옵션을 지정합니다.

    • DHCP 활성화 - 이 서브넷에 DHCP 서비스를 활성화합니다. DHCP를 사용하여 인스턴스에 대한 IP 설정 배포를 자동화할 수 있습니다.
    • IPv6 주소 - 구성 모드. IPv6 네트워크를 생성하는 경우 IPv6 주소 및 추가 정보를 할당하는 방법을 지정해야 합니다.

      • 옵션 없음 - IP 주소를 수동으로 설정하거나 주소 할당에 비 OpenStack 인식 방법을 사용하려면 이 옵션을 선택합니다.
      • RuntimeClass( stateless Address Autoconfiguration) - Instances는 OpenStack Networking 라우터에서 전송된 라우터 알림(RA) 메시지를 기반으로 IPv6 주소를 생성합니다. 이 구성을 사용하여 ra_mode가 slaac로 설정되고 address_mode가 slaac로 설정된 OpenStack Networking 서브넷을 생성합니다.
      • DHCPv6 stateful - Instances는 OpenStack Networking DHCPv6 서비스에서 IPv6 주소와 추가 옵션(예: DNS)을 수신합니다. 이 구성을 사용하여 ra_mode가 dhcpv6-stateful로 설정된 서브넷을 생성하고 address_mode가 dhcpv6-stateful로 설정된 서브넷을 생성합니다.
      • DHCPv6 상태 비저장 - 인스턴스는 OpenStack Networking 라우터에서 전송된 라우터 알림(RA) 메시지를 기반으로 IPv6 주소를 생성합니다. 추가 옵션(예: DNS)은 OpenStack Networking DHCPv6 서비스에서 할당됩니다. 이 구성을 사용하여 ra_mode가 dhcpv6-stateless로 설정되고 address_mode가 dhcpv6-stateless로 설정된 서브넷을 생성합니다.
    • 할당 풀 - DHCP를 할당할 IP 주소 범위입니다. 예를 들어 192.168.22.100,192.168.22.150 값은 할당에 사용 가능한 해당 범위의 모든 주소를 사용합니다.
    • DNS 이름 서버 - 네트워크에서 사용 가능한 DNS 서버의 IP 주소입니다. DHCP는 이름 확인을 위해 이러한 주소를 인스턴스에 배포합니다.

      중요

      DNS와 같은 전략적 서비스의 경우 클라우드에서 호스팅하지 않는 것이 좋습니다. 예를 들어 클라우드 호스트 DNS가 있고 클라우드가 작동하지 않는 경우 DNS를 사용할 수 없으며 클라우드 구성 요소는 서로 조회할 수 없습니다.

    • 호스트 경로 - 정적 호스트 경로입니다. 먼저 대상 네트워크를 CIDR 형식으로 지정하고 라우팅에 사용할 다음 홉(예: 192.168.23.0/24, 10.1.31.1)을 지정합니다. 정적 경로를 인스턴스에 배포해야 하는 경우 이 값을 제공합니다.
  5. 생성을 클릭합니다.

    네트워크 탭에서 전체 네트워크를 볼 수 있습니다. 필요에 따라 편집 을 클릭하여 모든 옵션을 변경할 수도 있습니다. 인스턴스를 생성할 때 서브넷을 사용하도록 지금 구성할 수 있으며 지정된 DHCP 옵션이 수신됩니다.

3.8. 서브넷 작업

서브넷을 사용하여 인스턴스에 네트워크 연결을 부여합니다. 각 인스턴스는 인스턴스 생성 프로세스의 일부로 서브넷에 할당되므로 연결 요구 사항에 맞게 인스턴스를 올바르게 배치하는 것이 중요합니다.

기존 네트워크에서만 서브넷을 만들 수 있습니다. OpenStack Networking의 프로젝트 네트워크는 여러 서브넷을 호스팅할 수 있습니다. 이 기능은 동일한 네트워크에서 서로 다른 시스템을 호스팅하고 이러한 시스템을 격리하는 방법을 선호하려는 경우에 유용합니다.

예를 들어 데이터베이스 트래픽이 다른 서브넷을 통과하는 동안 웹 서버 트래픽만 하나의 서브넷에 있다고 지정할 수 있습니다.

서브넷은 서로 격리되며 다른 서브넷과 통신하려는 모든 인스턴스에 해당 트래픽이 라우터에서 전달해야 합니다. 따라서 서로에 대량의 트래픽이 필요한 동일한 서브넷에서 시스템을 그룹화하여 네트워크 대기 시간과 로드를 줄일 수 있습니다.

3.9. 서브넷 생성

서브넷을 만들려면 다음 단계를 따르십시오.

  1. 대시보드에서 Project > Network > Networks 를 선택하고 Networks 보기에서 네트워크 이름을 클릭합니다.
  2. Create Subnet 을 클릭하고 다음 값을 지정합니다.

    필드설명

    서브넷 이름

    설명 서브넷 이름입니다.

    네트워크 주소

    IP 주소 범위 및 서브넷 마스크를 하나의 값으로 포함하는 CIDR 형식의 주소입니다. CIDR 주소를 확인하려면 서브넷 마스크에 마스킹된 비트 수를 계산하고 해당 값을 IP 주소 범위에 추가합니다. 예를 들어 서브넷 마스크 255.255.255.0에는 마스크된 비트가 24개 있습니다. IPv4 주소 범위 192.168.122.0과 함께 이 마스크를 사용하려면 주소 192.168.122.0/24를 지정합니다.

    IP 버전

    유효한 유형이 IPv4 또는 IPv6인 인터넷 프로토콜 버전입니다. Network Address(네트워크 주소) 필드의 IP 주소 범위는 선택한 프로토콜 버전과 일치해야 합니다.

    게이트웨이 IP

    기본 게이트웨이에 대한 라우터 인터페이스의 IP 주소입니다. 이 주소는 외부 위치로 향하는 트래픽을 라우팅하기 위한 다음 홉이며, 네트워크 주소 필드에 지정하는 범위 내에 있어야 합니다. 예를 들어 CIDR 네트워크 주소가 192.168.122.0/24인 경우 기본 게이트웨이는 192.168.122.1일 수 있습니다.

    게이트웨이 비활성화

    전달을 비활성화하고 서브넷을 격리합니다.

  3. 다음을 클릭하여 DHCP 옵션을 지정합니다.

    • DHCP 활성화 - 이 서브넷에 DHCP 서비스를 활성화합니다. DHCP를 사용하여 인스턴스에 대한 IP 설정 배포를 자동화할 수 있습니다.
    • IPv6 주소 - 구성 모드. IPv6 네트워크를 생성하는 경우 IPv6 주소 및 추가 정보를 할당하는 방법을 지정해야 합니다.

      • 옵션 없음 - IP 주소를 수동으로 설정하거나 주소 할당에 비 OpenStack 인식 방법을 사용하려면 이 옵션을 선택합니다.
      • RuntimeClass( stateless Address Autoconfiguration) - Instances는 OpenStack Networking 라우터에서 전송된 라우터 알림(RA) 메시지를 기반으로 IPv6 주소를 생성합니다. 이 구성을 사용하여 ra_mode가 slaac로 설정되고 address_mode가 slaac로 설정된 OpenStack Networking 서브넷을 생성합니다.
      • DHCPv6 stateful - Instances는 OpenStack Networking DHCPv6 서비스에서 IPv6 주소와 추가 옵션(예: DNS)을 수신합니다. 이 구성을 사용하여 ra_mode가 dhcpv6-stateful로 설정된 서브넷을 생성하고 address_mode가 dhcpv6-stateful로 설정된 서브넷을 생성합니다.
      • DHCPv6 상태 비저장 - 인스턴스는 OpenStack Networking 라우터에서 전송된 라우터 알림(RA) 메시지를 기반으로 IPv6 주소를 생성합니다. 추가 옵션(예: DNS)은 OpenStack Networking DHCPv6 서비스에서 할당됩니다. 이 구성을 사용하여 ra_mode가 dhcpv6-stateless로 설정되고 address_mode가 dhcpv6-stateless로 설정된 서브넷을 생성합니다.
    • 할당 풀 - DHCP를 할당할 IP 주소 범위입니다. 예를 들어 192.168.22.100,192.168.22.150 값은 할당에 사용 가능한 해당 범위의 모든 주소를 사용합니다.
    • DNS 이름 서버 - 네트워크에서 사용 가능한 DNS 서버의 IP 주소입니다. DHCP는 이름 확인을 위해 이러한 주소를 인스턴스에 배포합니다.
    • 호스트 경로 - 정적 호스트 경로입니다. 먼저 대상 네트워크를 CIDR 형식으로 지정하고 라우팅에 사용할 다음 홉(예: 192.168.23.0/24, 10.1.31.1)을 지정합니다. 정적 경로를 인스턴스에 배포해야 하는 경우 이 값을 제공합니다.
  4. 생성을 클릭합니다.

    서브넷 목록에서 서브넷을 볼 수 있습니다. 필요에 따라 편집 을 클릭하여 모든 옵션을 변경할 수도 있습니다. 인스턴스를 생성할 때 서브넷을 사용하도록 지금 구성할 수 있으며 지정된 DHCP 옵션이 수신됩니다.

3.10. 라우터 추가

OpenStack Networking은 SDN 기반 가상 라우터를 사용하여 라우팅 서비스를 제공합니다. 라우터는 인스턴스에서 실제 네트워크에 있는 서브넷을 포함하여 외부 서브넷과 통신해야 합니다. 라우터 및 서브넷은 인터페이스를 사용하여 연결합니다. 각 서브넷에 자체 인터페이스가 필요합니다.

라우터의 기본 게이트웨이는 라우터에서 수신한 모든 트래픽에 대한 다음 홉을 정의합니다. 해당 네트워크는 일반적으로 가상 브리지를 사용하여 트래픽을 외부 물리적 네트워크로 라우팅하도록 구성됩니다.

라우터를 생성하려면 다음 단계를 완료합니다.

  1. 대시보드에서 Project > Network >라우터 를 선택하고 Create Router 를 클릭합니다.
  2. 새 라우터에 대한 설명 이름을 입력하고 라우터 생성 을 클릭합니다.
  3. router1 목록에서 새 라우터의 항목 옆에 있는 Set Gateway 클릭합니다.
  4. External Network (외부 네트워크) 목록에서 외부 위치로 향하는 트래픽을 수신할 네트워크를 지정합니다.
  5. Set Gateway 를 클릭합니다.

    라우터를 추가한 후에는 이 라우터를 사용하여 트래픽을 보내도록 만든 서브넷을 구성해야 합니다. 서브넷과 라우터 간의 인터페이스를 생성하여 이 작업을 수행합니다.

중요

서브넷의 기본 경로를 덮어쓸 수 없습니다. 서브넷의 기본 경로가 제거되면 L3 에이전트가 라우터 네임스페이스에서 해당 경로를 자동으로 제거하고 네트워크 트래픽은 연결된 서브넷으로 이동할 수 없습니다. 기존 라우터 네임스페이스 경로가 제거된 경우 이 문제를 해결하려면 다음 단계를 수행합니다.

  1. 서브넷의 모든 유동 IP의 연결을 끊습니다.
  2. 서브넷에서 라우터를 분리합니다.
  3. 라우터를 서브넷에 다시 연결합니다.
  4. 모든 유동 IP를 다시 연결합니다.

3.11. 모든 리소스 삭제 및 프로젝트 삭제

openstack project purge 명령을 사용하여 특정 프로젝트에 속하는 모든 리소스와 프로젝트를 삭제할 수도 있습니다.

예를 들어 test-project 프로젝트의 리소스를 삭제한 다음 프로젝트를 삭제하려면 다음 명령을 실행합니다.

# openstack project list
+----------------------------------+--------------+
| ID                               | Name         |
+----------------------------------+--------------+
| 02e501908c5b438dbc73536c10c9aac0 | test-project |
| 519e6344f82e4c079c8e2eabb690023b | services     |
| 80bf5732752a41128e612fe615c886c6 | demo         |
| 98a2f53c20ce4d50a40dac4a38016c69 | admin        |
+----------------------------------+--------------+

# openstack project purge --project 02e501908c5b438dbc73536c10c9aac0

3.12. 라우터 삭제

연결된 인터페이스가 없는 경우 라우터를 삭제할 수 있습니다.

인터페이스를 제거하고 라우터를 삭제하려면 다음 단계를 완료합니다.

  1. 대시보드에서 Project > Network >라우터 를 선택하고 삭제할 라우터 이름을 클릭합니다.
  2. 내부 인터페이스 유형의 인터페이스를 선택하고 Delete Interfaces (인터페이스 삭제)를 클릭합니다.
  3. vGPU 목록에서 대상 라우터를 선택하고 Delete router 를 클릭합니다.

3.13. 서브넷 삭제

더 이상 사용하지 않는 경우 서브넷을 삭제할 수 있습니다. 그러나 인스턴스가 서브넷을 사용하도록 여전히 구성된 경우 삭제 시도가 실패하고 대시보드에 오류 메시지가 표시됩니다.

네트워크에서 특정 서브넷을 삭제하려면 다음 단계를 완료합니다.

  1. 대시보드에서 Project > Network > Networks 를 선택합니다.
  2. 네트워크 이름을 클릭합니다.
  3. 대상 서브넷을 선택하고 Delete Subnets 를 클릭합니다.

3.14. 네트워크 삭제

이전에 생성된 네트워크, 하우스키핑 또는 해제 프로세스의 일부로 삭제해야 하는 경우가 있습니다. 먼저 네트워크를 삭제하기 전에 네트워크가 여전히 사용 중인 인터페이스를 제거하거나 분리해야 합니다.

프로젝트에서 종속 인터페이스와 함께 네트워크를 삭제하려면 다음 단계를 완료합니다.

  1. 대시보드에서 Project > Network > Networks 를 선택합니다.

    대상 네트워크 서브넷과 연결된 모든 라우터 인터페이스를 제거합니다.

    인터페이스를 제거하려면 Networks 목록에서 대상 네트워크를 클릭하여 삭제할 네트워크의 ID 번호를 찾고 ID 필드를 확인합니다. 네트워크와 연결된 모든 서브넷은 네트워크 ID 필드에서 이 값을 공유합니다.

  2. Project > Network >라우터 로 이동하여 router 목록에서 가상 라우터의 이름을 클릭하고 삭제할 서브넷에 연결된 인터페이스를 찾습니다.

    게이트웨이 IP로 제공된 IP 주소로 이 서브넷을 다른 서브넷과 구별할 수 있습니다. 인터페이스의 네트워크 ID가 이전 단계에서 기록해 둔 ID와 일치하는지 확인하여 차이를 추가로 확인할 수 있습니다.

  3. 삭제할 인터페이스의 Delete Interface (인터페이스 삭제) 버튼을 클릭합니다.
  4. Project > Network > Networks 를 선택하고 네트워크 이름을 클릭합니다.
  5. 삭제할 서브넷의 Delete Subnet ( 서브넷 삭제) 버튼을 클릭합니다.

    참고

    이 시점에서 서브넷을 여전히 제거할 수 없는 경우 어떤 인스턴스에서 아직 사용하지 않는지 확인합니다.

  6. Project > Network > Networks 를 선택하고 삭제하려는 네트워크를 선택합니다.
  7. Delete Networks (네트워크 삭제)를 클릭합니다.

4장. VM 인스턴스를 물리적 네트워크에 연결

flat 및 VLAN 공급자 네트워크를 사용하여 VM 인스턴스를 외부 네트워크에 직접 연결할 수 있습니다.

4.1. OpenStack Networking 토폴로지 개요

OpenStack Networking(neutron)에는 여러 노드 유형에 분산된 두 가지 범주의 서비스가 있습니다.

  • Neutron 서버 - 이 서비스는 OpenStack Networking과 상호 작용할 수 있는 최종 사용자 및 서비스를 위한 API를 제공하는 OpenStack Networking API 서버를 실행합니다. 또한 이 서버는 기본 데이터베이스와 통합되어 프로젝트 네트워크, 라우터 및 로드 밸런서 세부 정보를 저장하고 검색합니다.
  • Neutron 에이전트 - OpenStack 네트워킹에 대한 네트워크 기능을 수행하는 서비스입니다.

    • neutron-dhcp-agent - 프로젝트 개인 네트워크의 DHCP IP 주소 지정을 관리합니다.
    • Neutron-l3-agent - 프로젝트 프라이빗 네트워크, 외부 네트워크 등 간에 계층 3 라우팅을 수행합니다.
  • 컴퓨팅 노드 - 이 노드는 인스턴스라고도 하는 가상 머신을 실행하는 하이퍼바이저를 호스팅합니다. 인스턴스에 외부 연결을 제공하려면 컴퓨팅 노드를 네트워크에 직접 연결해야 합니다. 일반적으로 이 노드는 l2 에이전트(예: neutron-openvswitch-agent )가 실행되는 위치입니다.

4.2. OpenStack Networking 서비스 배치

OpenStack Networking 서비스는 동일한 물리 서버에서 또는 해당 역할에 따라 이름이 지정된 별도의 전용 서버에서 함께 실행할 수 있습니다.

  • Controller 노드 - API 서비스를 실행하는 서버입니다.
  • 네트워크 노드 - OpenStack Networking 에이전트를 실행하는 서버입니다.
  • 컴퓨팅 노드 - 인스턴스를 호스팅하는 하이퍼바이저 서버입니다.

이 장의 단계는 이러한 세 가지 노드 유형을 포함하는 환경에 적용됩니다. 배포에 동일한 물리 노드에 컨트롤러 및 네트워크 노드 역할이 모두 있는 경우 해당 서버의 두 섹션에서 단계를 수행해야 합니다. 이는 HA(고가용성) 환경에도 적용됩니다. 이 환경은 세 개의 노드 모두 HA를 사용하여 컨트롤러 노드와 네트워크 노드 서비스를 실행할 수 있습니다. 따라서 세 노드 모두에서 컨트롤러 및 네트워크 노드에 적용 가능한 섹션의 단계를 완료해야 합니다.

4.3. 플랫 공급자 네트워크 구성

플랫 공급자 네트워크를 사용하여 인스턴스를 외부 네트워크에 직접 연결할 수 있습니다. 이 기능은 물리적 네트워크와 물리적 인터페이스가 여러 개 있고 각 컴퓨팅 및 네트워크 노드를 해당 외부 네트워크에 연결하려는 경우에 유용합니다.

사전 요구 사항

  • 물리적 네트워크가 여러 개 있습니다.

    이 예에서는 각각 physnet1 및 physnet 2 라는 물리적 네트워크를 사용합니다.

  • 개별 물리적 인터페이스가 있습니다.

    이 예에서는 각각 별도의 물리적 인터페이스인 eth0eth1 을 사용합니다.

절차

  1. 언더클라우드 호스트에서 stack 사용자로 로그인한 사용자 지정 YAML 환경 파일을 생성합니다.

    예제

    $ vi /home/stack/templates/my-modules-environment.yaml

    작은 정보

    Red Hat OpenStack Platform Orchestration 서비스(heat)는 템플릿 이라는 일련의 계획을 사용하여 환경을 설치하고 구성합니다. 오케스트레이션 템플릿에 대한 사용자 지정을 제공하는 특수한 유형의 템플릿인 사용자 지정 환경 파일을 사용하여 오버클라우드의 부분을 사용자 지정할 수 있습니다.

  2. parameter_defaults 아래의 YAML 환경 파일에서 NeutronBridgeMappings 를 사용하여 외부 네트워크에 액세스하는 데 사용되는 OVS 브리지를 지정합니다.

    예제

    parameter_defaults:
      NeutronBridgeMappings: 'physnet1:br-net1,physnet2:br-net2'

  3. 컨트롤러 및 컴퓨팅 노드에 대한 사용자 정의 NIC 구성 템플릿에서 인터페이스가 연결된 브릿지를 구성합니다.

    예제

    ...
                  - type: ovs_bridge
                    name: br-net1
                    mtu: 1500
                    use_dhcp: false
                    members:
                    - type: interface
                      name: eth0
                      mtu: 1500
                      use_dhcp: false
                      primary: true
                  - type: ovs_bridge
                    name: br-net2
                    mtu: 1500
                    use_dhcp: false
                    members:
                    - type: interface
                      name: eth1
                      mtu: 1500
                      use_dhcp: false
                      primary: true
    ...

  4. openstack overcloud deploy 명령을 실행하고 수정된 사용자 지정 NIC 템플릿 및 새 환경 파일을 포함하여 템플릿과 환경 파일을 포함합니다.

    중요

    후속 환경 파일에 정의된 매개 변수와 리소스가 우선하므로 환경 파일의 순서가 중요합니다.

    예제

    $ openstack overcloud deploy --templates \
    -e [your-environment-files] \
    -e /usr/share/openstack-tripleo-heat-templates/environments/services/my-neutron-environment.yaml

검증

  1. 외부 네트워크(public1)를 플랫 네트워크로 생성하고 구성된 물리적 네트워크(physnet1)와 연결합니다.

    다른 사용자가 외부 네트워크에 직접 연결하는 VM 인스턴스를 생성하도록 공유 네트워크( --share사용)로 구성합니다.

    예제

    # openstack network create --share --provider-network-type flat --provider-physical-network physnet1 --external public01

  2. openstack subnet create 명령을 사용하여 서브넷(public_subnet)을 생성합니다.

    예제

    # openstack subnet create --no-dhcp --allocation-pool start=192.168.100.20,end=192.168.100.100 --gateway 192.168.100.1 --network public01 public_subnet

  3. VM 인스턴스를 생성하고 새로 생성한 외부 네트워크에 직접 연결합니다.

    예제

    $ openstack server create --image rhel --flavor my_flavor --network public01 my_instance

추가 리소스

4.4. 플랫 공급자 네트워크 패킷 흐름은 어떻게 작동합니까?

이 섹션에서는 플랫 공급자 네트워크 구성이 있는 인스턴스에서 트래픽이 또는 인스턴스로 이동하는 방법을 자세히 설명합니다.

플랫 공급자 네트워크의 발신 트래픽 흐름

다음 다이어그램에서는 인스턴스를 떠나고 외부 네트워크에서 직접 들어오는 트래픽에 대한 패킷 흐름을 설명합니다. br-ex 외부 브리지를 구성한 후 물리적 인터페이스를 브리지에 추가하고 Compute 노드에 인스턴스를 생성합니다. 인터페이스 및 브리지의 결과 구성은 다음 다이어그램의 구성과 유사합니다( iptables_hybrid 방화벽 드라이버 사용).

네트워크 패킷 흐름 - 발신
  1. 패킷은 인스턴스의 eth0 인터페이스를 종료하고 linux bridge qbr-xx에 도달합니다.
  2. bridge qbr-xx 는 veth 쌍 qvb -xx <-> qvo-xxx를 사용하여 br- int 에 연결됩니다. 이는 브리지가 보안 그룹에서 정의한 인바운드/아웃바운드 방화벽 규칙을 적용하는 데 사용되기 때문입니다.
  3. qvb-xx 인터페이스는 qbr-xx Linux 브리지에 연결되고 qvoxxbr-int Open vSwitch(OVS) 브리지에 연결됩니다.

'qbr-xx'Linux 브리지의 구성 예:

 # brctl show
qbr269d4d73-e7		8000.061943266ebb	no		qvb269d4d73-e7
							tap269d4d73-e7

br-intqvo-xx 구성:

 # ovs-vsctl show
  Bridge br-int
        fail_mode: secure
            Interface "qvof63599ba-8f"
        Port "qvo269d4d73-e7"
            tag: 5
            Interface "qvo269d4d73-e7"

참고

포트 qvo-xx 는 플랫 공급자 네트워크와 연결된 내부 VLAN 태그로 태그가 지정됩니다. 이 예에서 VLAN 태그는 5 입니다. 패킷이 qvo-xx 에 도달하면 패킷 헤더에 VLAN 태그가 추가됩니다.

그런 다음 패킷이 patch-peer int- br-ex <-> phy-br-ex를 사용하여 br-ex OVS 브리지로 이동합니다.

br-int 의 patch-peer 구성 예:

 # ovs-vsctl show
    Bridge br-int
        fail_mode: secure
       Port int-br-ex
            Interface int-br-ex
                type: patch
                options: {peer=phy-br-ex}

br-ex 의 patch-peer 구성 예:

    Bridge br-ex
        Port phy-br-ex
            Interface phy-br-ex
                type: patch
                options: {peer=int-br-ex}
        Port br-ex
            Interface br-ex
                type: internal

이 패킷이 br-exphy-br-ex 에 도달하면 br-ex 내부의 OVS 흐름은 VLAN 태그 (5)를 제거하고 물리적 인터페이스로 전달합니다.

다음 예에서 출력은 phy -br-ex의 포트 번호를 2 로 보여줍니다.

 # ovs-ofctl show br-ex
OFPT_FEATURES_REPLY (xid=0x2): dpid:00003440b5c90dc6
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC SET_DL_DST SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE

 2(phy-br-ex): addr:ba:b5:7b:ae:5c:a2
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max

다음 출력은 VLAN 태그가 5 (dl_vlan=5)인 phy-br-ex (in_port=2)에 도달하는 모든 패킷을 보여줍니다. 또한 br-ex의 OVS 흐름은 VLAN 태그를 제거하고 패킷을 물리적 인터페이스로 전달합니다.

# ovs-ofctl dump-flows br-ex
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=4703.491s, table=0, n_packets=3620, n_bytes=333744, idle_age=0, priority=1 actions=NORMAL
 cookie=0x0, duration=3890.038s, table=0, n_packets=13, n_bytes=1714, idle_age=3764, priority=4,in_port=2,dl_vlan=5 actions=strip_vlan,NORMAL
 cookie=0x0, duration=4702.644s, table=0, n_packets=10650, n_bytes=447632, idle_age=0, priority=2,in_port=2 actions=drop

실제 인터페이스가 또 다른 VLAN 태그 지정 인터페이스인 경우 물리적 인터페이스는 태그를 패킷에 추가합니다.

플랫 공급자 네트워크의 들어오는 트래픽 흐름

이 섹션에는 인스턴스의 인터페이스에 도달할 때까지 외부 네트워크에서 들어오는 트래픽 흐름에 대한 정보가 포함되어 있습니다.

네트워크 패킷 흐름 - 수신
  1. 들어오는 트래픽은 물리적 노드의 eth1 에 도달합니다.
  2. 패킷은 br-ex 브리지에 전달됩니다.
  3. 패킷은 patch-peer phy -br-ex <--> int-br-ex를 통해 br-int 로 이동합니다.

다음 예에서 int-br-ex 는 포트 번호 15 를 사용합니다. 15(int-br-ex) 를 포함하는 항목을 참조하십시오.

 # ovs-ofctl show br-int
OFPT_FEATURES_REPLY (xid=0x2): dpid:00004e67212f644d
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC SET_DL_DST SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE
 15(int-br-ex): addr:12:4e:44:a9:50:f4
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max

br-int에서 트래픽 흐름 관찰

  1. 패킷이 int-br-ex 에 도달하면 br-int 브리지 내의 OVS 흐름 규칙이 패킷을 수정하여 내부 VLAN 태그 5 를 추가합니다. actions=mod_vlan_vid:5 에 대한 항목을 참조하십시오.

     # ovs-ofctl dump-flows br-int
    NXST_FLOW reply (xid=0x4):
     cookie=0x0, duration=5351.536s, table=0, n_packets=12118, n_bytes=510456, idle_age=0, priority=1 actions=NORMAL
     cookie=0x0, duration=4537.553s, table=0, n_packets=3489, n_bytes=321696, idle_age=0, priority=3,in_port=15,vlan_tci=0x0000 actions=mod_vlan_vid:5,NORMAL
     cookie=0x0, duration=5350.365s, table=0, n_packets=628, n_bytes=57892, idle_age=4538, priority=2,in_port=15 actions=drop
     cookie=0x0, duration=5351.432s, table=23, n_packets=0, n_bytes=0, idle_age=5351, priority=0 actions=drop
  2. 두 번째 규칙은 VLAN 태그가 없는 int-br-ex(in_port=15)에 도달하는 패킷을 관리합니다(vlan_tci=0x0000). 이 규칙은 VLAN 태그 5를 패킷(actions=mod_vlan_vid:5,NORMAL)에 추가하고 qvoxxx 로 전달합니다.
  3. qvoXXX 는 VLAN 태그를 제거한 후 패킷을 수락하고 qvbxx 로 전달합니다.
  4. 그런 다음 패킷이 인스턴스에 도달합니다.
참고

VLAN 태그 5는 플랫 공급자 네트워크가 있는 테스트 Compute 노드에서 사용된 VLAN의 예입니다. 이 값은 neutron-openvswitch-agent 에 의해 자동으로 할당되었습니다. 이 값은 자체 플랫 공급자 네트워크에 따라 다를 수 있으며 두 개의 Compute 노드에서 동일한 네트워크에 따라 다를 수 있습니다.

4.5. 플랫 공급자 네트워크에서 인스턴스 물리적 네트워크 연결 문제 해결

"마이플 공급자 네트워크 패킷 흐름은 어떻게 작동합니까?"에서 제공된 출력은 플랫 공급자 네트워크 문제 해결을 위한 충분한 디버깅 정보를 제공하므로 문제가 발생할 수 있습니다. 다음 단계에는 문제 해결 프로세스에 대한 추가 정보가 포함되어 있습니다.

절차

  1. bridge_mappings.

    사용하는 물리적 네트워크 이름이 bridge_mapping 구성의 내용과 일치하는지 확인합니다.

    예제

    이 예에서 물리적 네트워크 이름은, gnet 1 입니다.

    $ openstack network show provider-flat

    샘플 출력

    ...
    | provider:physical_network | physnet1
    ...

    예제

    이 예에서 bridge_mapping 구성의 콘텐츠도, Resticsnet 1 입니다.

    $ grep bridge_mapping /etc/neutron/plugins/ml2/openvswitch_agent.ini

    샘플 출력

    bridge_mappings = physnet1:br-ex

  2. 네트워크 구성을 검토합니다.

    네트워크가 외부로 생성되었는지 확인하고 flat 유형을 사용합니다.

    예제

    이 예에서는 provider-flat 네트워크에 대한 세부 정보를 쿼리합니다.

    $ openstack network show provider-flat

    샘플 출력

    ...
    | provider:network_type     | flat                                 |
    | router:external           | True                                 |
    ...

  3. patch-peer를 검토합니다.

    br-intbr-ex 가 patch-peer int-br-ex <-->ECDHE-br-ex 를 사용하여 연결되어 있는지 확인합니다.

    $ ovs-vsctl show

    샘플 출력

      Bridge br-int
          fail_mode: secure
         Port int-br-ex
              Interface int-br-ex
                  type: patch
                  options: {peer=phy-br-ex}

    샘플 출력

    br-ex 의 patch-peer 구성 :

        Bridge br-ex
            Port phy-br-ex
                Interface phy-br-ex
                    type: patch
                    options: {peer=int-br-ex}
            Port br-ex
                Interface br-ex
                    type: internal

    이 연결은 neutron-openvswitch-agent 서비스를 재시작할 때 /etc/neutron/plugins/ml2/openvswitch_agent.inibridge_mapping 이 올바르게 구성된 경우 생성됩니다.

    서비스를 다시 시작한 후 연결이 생성되지 않은 경우 bridge_mapping 설정을 다시 확인합니다.

  4. 네트워크 흐름을 검토합니다.

    ovs-ofctl dump-flows br-exovs-ofctl dump-flows br-int 를 실행하고, 흐름이 발신 패킷의 내부 VLAN ID를 제거하고 들어오는 패킷의 VLAN ID를 추가하는지 검토합니다. 이 흐름은 특정 컴퓨팅 노드에서 이 네트워크에 대한 인스턴스를 생성할 때 처음 추가됩니다.

    1. 인스턴스를 생성한 후 이 흐름이 생성되지 않은 경우 네트워크가 flat, external 으로 생성되고 physical_network 이름이 올바른지 확인합니다. 또한 bridge_mapping 설정을 검토합니다.
    2. 마지막으로 ifcfg-br-exifcfg-ethx 구성을 검토합니다. ethXbr-ex 내의 포트로 추가되고 ifcfg-br-exifcfg-ethxip a 의 출력에 UP 플래그가 있는지 확인합니다.

      샘플 출력

      다음 출력은 eth1br-ex 의 포트입니다.

          Bridge br-ex
              Port phy-br-ex
                  Interface phy-br-ex
                      type: patch
                      options: {peer=int-br-ex}
              Port "eth1"
                  Interface "eth1"

      예제

      다음 예제에서는 eth1 이 OVS 포트로 구성되어 있으며 커널에서 모든 패킷을 인터페이스에서 전송하고 OVS 브리지 br-ex 로 보내는 것을 알고 있음을 보여줍니다. 이는 항목인 마스터 ovs-system 에서 확인할 수 있습니다.

      $ ip a
      5: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP qlen 1000

4.6. VLAN 공급자 네트워크 구성

단일 NIC의 VLAN 태그 지정 인터페이스를 여러 공급자 네트워크에 연결하면 이러한 새 VLAN 공급자 네트워크가 VM 인스턴스를 외부 네트워크에 직접 연결할 수 있습니다.

사전 요구 사항

  • VLAN 범위가 있는 물리적 네트워크가 있습니다.

    이 예에서는 VLAN 범위가 171-172physnet1 이라는 물리적 네트워크를 사용합니다.

  • 네트워크 노드와 컴퓨팅 노드는 물리적 인터페이스를 사용하여 물리적 네트워크에 연결됩니다.

    이 예에서는 물리적 인터페이스 eth1을 사용하여 물리적 네트워크 physnet1 에 연결된 네트워크 노드 및 컴퓨팅 노드를 사용합니다.

  • 이러한 인터페이스가 연결된 스위치 포트는 필요한 VLAN 범위를 트렁크하도록 구성해야 합니다.

절차

  1. 언더클라우드 호스트에서 stack 사용자로 로그인한 사용자 지정 YAML 환경 파일을 생성합니다.

    예제

    $ vi /home/stack/templates/my-modules-environment.yaml

    작은 정보

    Red Hat OpenStack Platform Orchestration 서비스(heat)는 템플릿 이라는 일련의 계획을 사용하여 환경을 설치하고 구성합니다. 오케스트레이션 템플릿에 대한 사용자 지정을 제공하는 특수한 유형의 템플릿인 사용자 지정 환경 파일을 사용하여 오버클라우드의 부분을 사용자 지정할 수 있습니다.

  2. parameter_defaults 아래의 YAML 환경 파일에서 NeutronTypeDrivers 를 사용하여 네트워크 유형 드라이버를 지정합니다.

    예제

    parameter_defaults:
      NeutronTypeDrivers: vxlan,flat,vlan

  3. 사용 중인 물리적 네트워크 및 VLAN 범위를 반영하도록 NeutronNetworkVLANRanges 설정을 구성합니다.

    예제

    parameter_defaults:
      NeutronTypeDrivers: 'vxlan,flat,vlan'
      NeutronNetworkVLANRanges: 'physnet1:171:172'

  4. 외부 네트워크 브리지(br-ex)를 만들고 포트(eth1)와 연결합니다.

    이 예제에서는 br-ex 를 사용하도록 eth1 을 구성합니다.

    예제

    parameter_defaults:
      NeutronTypeDrivers: 'vxlan,flat,vlan'
      NeutronNetworkVLANRanges: 'physnet1:171:172'
      NeutronBridgeMappings: 'datacentre:br-ex,tenant:br-int'

  5. openstack overcloud deploy 명령을 실행하고 이 새 환경 파일을 포함하여 코어 템플릿과 환경 파일을 포함합니다.

    중요

    후속 환경 파일에 정의된 매개 변수와 리소스가 우선하므로 환경 파일의 순서가 중요합니다.

    예제

    $ openstack overcloud deploy --templates \
    -e [your-environment-files] \
    -e /usr/share/openstack-tripleo-heat-templates/environments/services/my-neutron-environment.yaml

검증

  1. 외부 네트워크를 vlan 유형으로 생성하고 구성된 physical_network 와 연결합니다.

    다음 예제 명령을 실행하여 VLAN 171용 네트워크와 VLAN 172용 네트워크 두 개를 생성합니다.

    예제

    $ openstack network create \
    			--provider-network-type vlan \
    			--provider-physical-network physnet1 \
    			--provider-segment 171 \
    			provider-vlan171
    
    $ openstack network create \
    			--provider-network-type vlan \
    			--provider-physical-network physnet1 \
    			--provider-segment 172 \
    			provider-vlan172

  2. 여러 서브넷을 만들고 외부 네트워크를 사용하도록 구성합니다.

    openstack subnet create 또는 대시보드를 사용하여 이러한 서브넷을 만들 수 있습니다. 네트워크 관리자로부터 받은 외부 서브넷 세부 정보가 각 VLAN과 올바르게 연결되어 있는지 확인합니다.

    이 예제에서 VLAN 171은 서브넷 10.65.217.0/24 를 사용하고 VLAN 172는 10.65.218.0/24 를 사용합니다.

    예제

    $ openstack subnet create \
    			--network provider-171 \
    			--subnet-range 10.65.217.0/24 \
    			--dhcp \
    			--gateway 10.65.217.254 \
    			subnet-provider-171
    
    $ openstack subnet create \
    			--network provider-172 \
    			--subnet-range 10.65.218.0/24 \
    			--dhcp \
    			--gateway 10.65.218.254 \
    			subnet-provider-172

추가 리소스

4.7. VLAN 공급자 네트워크 패킷 흐름은 어떻게 작동합니까?

이 섹션에서는 VLAN 공급자 네트워크 구성이 있는 인스턴스에서 트래픽이 또는 인스턴스로 이동하는 방법에 대해 자세히 설명합니다.

VLAN 공급자 네트워크의 발신 트래픽 흐름

다음 다이어그램은 인스턴스를 떠나고 VLAN 공급자 외부 네트워크에 직접 들어오는 트래픽에 대한 패킷 흐름을 설명합니다. 이 예에서는 두 개의 VLAN 네트워크(171 및 172)에 연결된 두 개의 인스턴스를 사용합니다. br-ex 를 구성한 후 물리적 인터페이스를 추가하고 Compute 노드에 인스턴스를 생성하면 인터페이스 및 브리지의 결과 구성이 다음 다이어그램의 구성과 유사합니다.

VLAN 공급자 네트워크의 네트워크 트래픽 - 발신
  1. 인스턴스의 eth0 인터페이스를 나가는 패킷은 인스턴스에 연결된 linux bridge qbr-xx 에 도달합니다.
  2. qbr-xx 는 veth 쌍 qvbxx <ECDHE qvoxxx 를 사용하여 br-int 에 연결됩니다.
  3. qvbxx 는 linux bridge qbr-xx 에 연결되고 qvoxx 는 Open vSwitch 브리지 br-int 에 연결됩니다.

Linux 브리지의 qbr-xx 구성의 예.

이 예제에서는 두 개의 인스턴스와 해당 linux 브리지 두 개를 제공합니다.

# brctl show
bridge name	bridge id		STP enabled	interfaces
qbr84878b78-63		8000.e6b3df9451e0	no		qvb84878b78-63
							tap84878b78-63

qbr86257b61-5d		8000.3a3c888eeae6	no		qvb86257b61-5d
							tap86257b61-5d

br-intqvoxx 구성:

                options: {peer=phy-br-ex}
        Port "qvo86257b61-5d"
            tag: 3

            Interface "qvo86257b61-5d"
        Port "qvo84878b78-63"
            tag: 2
            Interface "qvo84878b78-63"

  • qvoxx 는 VLAN 공급자 네트워크와 연결된 내부 VLAN 태그로 태그가 지정됩니다. 이 예에서 내부 VLAN 태그 2는 VLAN 공급자 네트워크 provider-171 과 연결되고 VLAN 태그 3은 VLAN 공급자 네트워크 provider-172 와 연결됩니다. 패킷이 qvoxx 에 도달하면 패킷 헤더에 이 VLAN 태그가 추가됩니다.
  • 그런 다음 패킷이 patch-peer int- br-ex <octets phy-br-ex 를 사용하여 br-ex OVS 브리지로 이동합니다. br-int 의 patch-peer 예:
    Bridge br-int
        fail_mode: secure
       Port int-br-ex
            Interface int-br-ex
                type: patch
                options: {peer=phy-br-ex}

br-ex 의 패치 피어 구성 예:

    Bridge br-ex
        Port phy-br-ex
            Interface phy-br-ex
                type: patch
                options: {peer=int-br-ex}
        Port br-ex
            Interface br-ex
                type: internal
  • 이 패킷이 br-exphy-br-ex 에 도달하면 br-ex 내부의 OVS 흐름이 내부 VLAN 태그를 VLAN 공급자 네트워크와 연결된 실제 VLAN 태그로 교체합니다.

다음 명령의 출력은 phy -br-ex의 포트 번호가 4 임을 보여줍니다.

# ovs-ofctl show br-ex
 4(phy-br-ex): addr:32:e7:a1:6b:90:3e
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max

다음 명령은 VLAN 태그 2(dl_vlan=2)가 있는 phy-br-ex(in_port=4)에 도달하는 모든 패킷을 보여줍니다. Open vSwitch는 VLAN 태그를 171(actions=mod_vlan_vid:171,NORMAL)로 바꾸고 패킷을 물리적 인터페이스로 전달합니다. 또한 명령은 VLAN 태그 3(dl_vlan=3)이 있는 phy-br-ex(in_port=4)에 도달하는 모든 패킷을 표시합니다. Open vSwitch는 VLAN 태그를 172(actions=mod_vlan_vid:172,NORMAL)로 바꾸고 패킷을 물리적 인터페이스로 전달합니다. neutron-openvswitch-agent는 이러한 규칙을 추가합니다.

# ovs-ofctl dump-flows br-ex
NXST_FLOW reply (xid=0x4):
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=6527.527s, table=0, n_packets=29211, n_bytes=2725576, idle_age=0, priority=1 actions=NORMAL
 cookie=0x0, duration=2939.172s, table=0, n_packets=117, n_bytes=8296, idle_age=58, priority=4,in_port=4,dl_vlan=3 actions=mod_vlan_vid:172,NORMAL
 cookie=0x0, duration=6111.389s, table=0, n_packets=145, n_bytes=9368, idle_age=98, priority=4,in_port=4,dl_vlan=2 actions=mod_vlan_vid:171,NORMAL
 cookie=0x0, duration=6526.675s, table=0, n_packets=82, n_bytes=6700, idle_age=2462, priority=2,in_port=4 actions=drop
  • 그런 다음 이 패킷은 물리 인터페이스 eth1 로 전달됩니다.

VLAN 공급자 네트워크의 들어오는 트래픽 흐름

다음 예제 흐름은 공급자 네트워크 provider-171에 VLAN 태그 2를 사용하고 공급자 네트워크 provider-172의 경우 VLAN 태그 3을 사용하여 컴퓨팅 노드에서 테스트되었습니다. 흐름은 통합 브리지 br-int에서 포트 18을 사용합니다.

VLAN 공급자 네트워크에는 다른 구성이 필요할 수 있습니다. 또한 네트워크에 대한 구성 요구 사항은 서로 다른 두 개의 컴퓨팅 노드 간에 다를 수 있습니다.

다음 명령의 출력은 포트 번호 18과 함께 int-br-ex 를 보여줍니다.

# ovs-ofctl show br-int
 18(int-br-ex): addr:fe:b7:cb:03:c5:c1
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max

다음 명령의 출력에서는 br-int의 흐름 규칙을 보여줍니다.

# ovs-ofctl dump-flows br-int
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=6770.572s, table=0, n_packets=1239, n_bytes=127795, idle_age=106, priority=1 actions=NORMAL

 cookie=0x0, duration=3181.679s, table=0, n_packets=2605, n_bytes=246456, idle_age=0,
 priority=3,in_port=18,dl_vlan=172 actions=mod_vlan_vid:3,NORMAL

 cookie=0x0, duration=6353.898s, table=0, n_packets=5077, n_bytes=482582, idle_age=0,
 priority=3,in_port=18,dl_vlan=171 actions=mod_vlan_vid:2,NORMAL

 cookie=0x0, duration=6769.391s, table=0, n_packets=22301, n_bytes=2013101, idle_age=0, priority=2,in_port=18 actions=drop

 cookie=0x0, duration=6770.463s, table=23, n_packets=0, n_bytes=0, idle_age=6770, priority=0 actions=drop

들어오는 흐름 예

이 예에서는 다음 br-int OVS 흐름을 보여줍니다.

cookie=0x0, duration=3181.679s, table=0, n_packets=2605, n_bytes=246456, idle_age=0,
priority=3,in_port=18,dl_vlan=172 actions=mod_vlan_vid:3,NORMAL
  • 외부 네트워크에서 VLAN 태그 172가 있는 패킷은 물리적 노드의 eth1 을 통해 br-ex 브리지에 도달합니다.
  • 패킷은 patch-peer phy-br- ex <-> int-br-ex를 통해 br- int 로 이동합니다.
  • 패킷은 흐름의 기준(in_port=18,dl_vlan=172)과 일치합니다.
  • 흐름 작업(actions=mod_vlan_vid:3,NORMAL)은 VLAN 태그 172를 내부 VLAN 태그 3으로 바꾸고 패킷을 일반 계층 2 처리로 인스턴스로 전달합니다.

4.8. VLAN 공급자 네트워크에서 인스턴스 물리적 네트워크 연결 문제 해결

VLAN 공급자 네트워크에서 연결 문제를 해결할 때 "VLAN 공급자 네트워크 패킷 흐름은 어떻게 작동합니까?"에 설명된 패킷 흐름을 참조하십시오. 또한 다음 구성 옵션을 검토합니다.

절차

  1. bridge_mapping 구성에 사용된 물리적 네트워크 이름이 물리적 네트워크 이름과 일치하는지 확인합니다.

    예제

    $ openstack network show provider-vlan171

    샘플 출력

    ...
    | provider:physical_network | physnet1
    ...

    예제

    $ grep bridge_mapping /etc/neutron/plugins/ml2/openvswitch_agent.ini

    샘플 출력

    이 샘플 출력에서 물리적 네트워크 이름인ECDHEs net1bridge_mapping 구성에 사용된 이름과 일치합니다.

    bridge_mappings = physnet1:br-ex
  2. 네트워크가 외부 로서 생성되었으며 vlan 이고 올바른 segmentation_id 값을 사용하는지 확인합니다.

    예제

    $ openstack network show provider-vlan171

    샘플 출력

    ...
    | provider:network_type     | vlan                                 |
    | provider:physical_network | physnet1                             |
    | provider:segmentation_id  | 171                                  |
    ...

  3. patch-peer를 검토합니다.

    br-intbr-ex 가 patch-peer int-br-ex <-->ECDHE-br-ex 를 사용하여 연결되어 있는지 확인합니다.

    $ ovs-vsctl show

    이 연결은 bridge_mapping/etc/neutron/plugins/ml2/openvswitch_agent.ini 에 올바르게 구성된 경우 neutron-openvswitch-agent 를 다시 시작하는 동안 생성됩니다.

    서비스를 다시 시작한 후에도 생성되지 않은 경우 bridge_mapping 설정을 다시 확인합니다.

  4. 네트워크 흐름을 검토합니다.

    1. 발신 패킷의 흐름을 검토하려면 ovs-ofctl dump-flows br-exovs-ofctl dump-flows br-int 를 실행하고 흐름이 내부 VLAN ID를 외부 VLAN ID(segmentation_id)에 매핑하는지 확인합니다.
    2. 들어오는 패킷의 경우 외부 VLAN ID를 내부 VLAN ID에 매핑합니다.

      이 흐름은 이 네트워크에 처음으로 인스턴스를 생성할 때 neutron OVS 에이전트에 의해 추가됩니다.

    3. 인스턴스를 생성한 후 이 흐름이 생성되지 않으면 네트워크가 vlan 으로 생성되고, external 이고, physical_network 이름이 올바른지 확인합니다. 또한 bridge_mapping 설정을 다시 확인합니다.
    4. 마지막으로 ifcfg-br-exifcfg-ethx 구성을 다시 확인합니다.

      br-ex 에 포트 ethX, ifcfg-br-exifcfg-ethx 모두 ip a 명령의 출력에 UP 플래그가 있는지 확인합니다.

      예제

      $ ovs-vsctl show

      이 샘플 출력에서 eth1br-ex 의 포트입니다.

          Bridge br-ex
              Port phy-br-ex
                  Interface phy-br-ex
                      type: patch
                      options: {peer=int-br-ex}
              Port "eth1"
                  Interface "eth1"

      예제

      $ ip a

      샘플 출력

      이 샘플 출력에서 eth1 은 포트로 추가되었으며 커널은 인터페이스에서 OVS 브리지 br-ex 로 모든 패킷을 이동하도록 구성되어 있습니다. 이는 마스터 ovs-system 항목에 의해 입증됩니다.

      5: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP qlen 1000

4.9. ML2/OVS 배포에서 공급자 네트워크의 멀티 캐스트 스누핑 활성화

RHOSP(Red Hat OpenStack Platform) 공급자 네트워크의 모든 포트로 멀티 캐스트 패킷의 플러딩을 방지하려면 멀티 캐스트 스누핑을 활성화해야 합니다. Open vSwitch 메커니즘 드라이버(ML2/OVS)와 함께 Modular Layer 2 플러그인을 사용하는 RHOSP 배포에서 YAML 형식의 환경 파일에 RHOSP Orchestration(heat) NeutronEnableIgmpSnooping 매개변수를 선언하여 이 작업을 수행합니다.

중요

멀티 캐스트 스누핑 구성을 프로덕션 환경에 적용하기 전에 철저하게 테스트하고 이해해야합니다. 잘못된 경우 멀티 캐스트가 중단되거나 잘못된 네트워크 동작이 발생할 수 있습니다.

사전 요구 사항

  • 구성에서는 ML2/OVS 공급자 네트워크만 사용해야 합니다.
  • 물리적 라우터도 IGMP 스누핑이 활성화되어 있어야 합니다.

    즉, 물리적 라우터는 OVS(및 물리적 네트워킹)에서 스누핑 캐시를 유지하기 위해 멀티 캐스트 그룹 멤버의 일반 IGMP 보고서를 요청하기 위해 공급자 네트워크에서 IGMP 쿼리 패킷을 보내야 합니다.

  • VM 인스턴스(또는 포트 보안 비활성화)에 인바운드 IGMP를 허용하려면 RHOSP Networking 서비스 보안 그룹 규칙이 있어야 합니다.

    이 예제에서는 ping_ssh 보안 그룹에 대한 규칙이 생성됩니다.

    예제

    $ openstack security group rule create --protocol igmp --ingress ping_ssh

절차

  1. 언더클라우드 호스트에서 stack 사용자로 로그인한 사용자 지정 YAML 환경 파일을 생성합니다.

    예제

    $ vi /home/stack/templates/my-ovs-environment.yaml

    작은 정보

    오케스트레이션 서비스(heat)에서는 템플릿이라는 플랜 세트를 사용하여 환경을 설치하고 구성합니다. 사용자 지정 환경 파일을 사용하여 오버클라우드의 속성을 사용자 지정할 수 있습니다. 이 파일은 heat 템플릿에 대한 사용자 지정을 제공하는 특수한 템플릿입니다.

  2. parameter_defaults 아래의 YAML 환경 파일에서 NeutronEnableIgmpSnooping을 true로 설정합니다.

    parameter_defaults:
        NeutronEnableIgmpSnooping: true
        ...
    중요

    콜론(:)과 true 사이에 공백 문자를 추가해야 합니다.

  3. openstack overcloud deploy 명령을 실행하고 코어 heat 템플릿, 환경 파일 및 이 새 사용자 지정 환경 파일을 포함합니다.

    중요

    후속 환경 파일에 정의된 매개변수 및 리소스가 우선하므로 환경 파일의 순서가 중요합니다.

    예제

    $ openstack overcloud deploy --templates \
    -e [your-environment-files] \
    -e /usr/share/openstack-tripleo-heat-templates/environments/services/my-ovs-environment.yaml

검증

  • 멀티 캐스트 스누핑이 활성화되었는지 확인합니다.

    예제

    # sudo ovs-vsctl list bridge br-int

    샘플 출력

    ...
    mcast_snooping_enable: true
    ...
    other_config: {mac-table-size="50000", mcast-snooping-disable-flood-unregistered=True}
    ...

추가 리소스

4.10. ML2/OVN 배포에서 멀티 캐스트 활성화

멀티 캐스트 트래픽을 지원하려면 멀티 캐스트 트래픽이 멀티캐스트 그룹의 가상 머신(VM) 인스턴스에 도달할 수 있도록 배포의 보안 구성을 수정합니다. 멀티 캐스트 트래픽 플러핑을 방지하려면 IGMP 스누핑을 활성화하십시오.

중요

멀티 캐스트 스누핑 구성을 테스트 및 이해하고 프로덕션 환경에 적용합니다. 잘못된 경우 멀티 캐스트가 중단되거나 잘못된 네트워크 동작이 발생할 수 있습니다.

사전 요구 사항

  • ML2/OVN 메커니즘 드라이버를 사용한 OpenStack 배포.

절차

  1. 적절한 VM 인스턴스로 멀티 캐스트 트래픽을 허용하도록 보안을 구성합니다. 예를 들어 IGMP querier의 IGMP 트래픽을 허용하는 보안 그룹 규칙과 VM 인스턴스를 입력하고 종료하는 세 번째 규칙과 멀티 캐스트 트래픽을 허용하는 세 번째 규칙을 만듭니다.

    예제

    보안 그룹 mySG 를 사용하면 IGMP 트래픽이 VM 인스턴스에 들어가 종료할 수 있습니다.

     openstack security group rule create --protocol igmp --ingress mySG
    
     openstack security group rule create --protocol igmp --egress mySG

    또 다른 규칙을 사용하면 멀티 캐스트 트래픽이 VM 인스턴스에 도달할 수 있습니다.

    openstack security group rule create  --protocol udp mySG

    보안 그룹 규칙을 설정하는 대신 일부 Operator는 네트워크에서 포트 보안을 선택적으로 비활성화하도록 선택합니다. 포트 보안을 비활성화하도록 선택하는 경우 관련 보안 위험을 고려하고 계획하십시오.

  2. heat 매개변수 NeutronEnableIgmpSnooping을 설정합니다. 언더클라우드 노드의 환경 파일에서 true 예를 들어 ovn-extras.yaml에 다음 행을 추가합니다.

    예제

    parameter_defaults:
            NeutronEnableIgmpSnooping: True

  3. 해당 환경과 관련된 기타 환경 파일과 함께 openstack overcloud deploy 명령에 환경 파일을 추가하고 오버클라우드를 배포합니다.

    $ openstack overcloud deploy \
    --templates \
    …
    -e <other_overcloud_environment_files> \
    
    -e ovn-extras.yaml \
    …

    <other_overcloud_environment_files> 를 기존 배포의 일부인 환경 파일 목록으로 바꿉니다.

검증

  1. 멀티 캐스트 스누핑이 활성화되었는지 확인합니다. northbound 데이터베이스 Logical_Switch 테이블을 나열합니다.

    $ ovn-nbctl list Logical_Switch

    샘플 출력

    _uuid         : d6a2fbcd-aaa4-4b9e-8274-184238d66a15
    other_config  : {mcast_flood_unregistered="false", mcast_snoop="true"}
    ...

    Networking 서비스(neutron) igmp_snooping_enable 구성은 OVN Northbound 데이터베이스의 Logical_Switch 테이블에 있는 other_config 열에 설정된 mcast_snoop 옵션으로 변환됩니다. mcast_flood_unregistered는 항상 "false"입니다.

  2. IGMP 그룹을 표시합니다.

    $ ovn-sbctl list IGMP_group

    샘플 출력

    _uuid    : 2d6cae4c-bd82-4b31-9c63-2d17cbeadc4e
    address  : "225.0.0.120"
    chassis  : 34e25681-f73f-43ac-a3a4-7da2a710ecd3
    datapath : eaf0f5cc-a2c8-4c30-8def-2bc1ec9dcabc
    ports    : [5eaf9dd5-eae5-4749-ac60-4c1451901c56, 8a69efc5-38c5-48fb-bbab-30f2bf9b8d45]
    ...

추가 리소스

4.11. 컴퓨팅 메타데이터 액세스 활성화

이 장에 설명된 대로 연결된 인스턴스는 공급자 외부 네트워크에 직접 연결되어 있으며 외부 라우터가 기본 게이트웨이로 구성되어 있습니다. OpenStack Networking(neutron) 라우터가 사용되지 않습니다. 즉, Neutron 라우터를 사용하여 인스턴스의 메타데이터 요청을 nova-metadata 서버로 프록시할 수 없으므로 cloud-init 를 실행하는 동안 오류가 발생할 수 있습니다. 그러나 이 문제는 dhcp 에이전트를 구성하여 메타데이터 요청을 프록시하여 해결할 수 있습니다. /etc/neutron/dhcp_agent.ini 에서 이 기능을 활성화할 수 있습니다. 예를 들면 다음과 같습니다.

enable_isolated_metadata = True

4.12. 부동 IP 주소

유동 IP가 이미 사설 네트워크에 연결되어 있어도 동일한 네트워크를 사용하여 인스턴스에 유동 IP 주소를 할당할 수 있습니다. 이 네트워크에서 유동 IP로 할당하는 주소는 네트워크 노드의 pxe -xxx 네임스페이스에 바인딩되고 연결된 개인 IP 주소에 대해 DNAT-SNAT 를 수행합니다. 반면 직접 외부 네트워크 액세스를 위해 할당하는 IP 주소는 인스턴스 내부에서 직접 바인딩되며 인스턴스가 외부 네트워크와 직접 통신할 수 있습니다.

5장. 부동 IP 주소 관리

개인, 고정 IP 주소 외에도 VM 인스턴스에는 다른 네트워크와 통신할 공용 또는 유동 IP 주소가 있을 수 있습니다. 이 섹션의 정보는 RHOSP(Red Hat OpenStack Platform) 네트워킹 서비스(neutron)를 사용하여 유동 IP를 생성하고 관리하는 방법을 설명합니다.

5.1. 부동 IP 풀 생성

유동 IP 주소를 사용하여 OpenStack 인스턴스로 수신 네트워크 트래픽을 보낼 수 있습니다. 먼저 유효한 라우팅 가능한 외부 IP 주소 풀을 정의해야 합니다. 그러면 인스턴스에 동적으로 할당할 수 있습니다. OpenStack Networking에서는 해당 유동 IP를 대상으로 들어오는 모든 트래픽을 유동 IP와 연결된 인스턴스로 라우팅합니다.

참고

OpenStack Networking에서는 CIDR 형식의 동일한 IP 범위의 모든 프로젝트(테넌트)에 유동 IP 주소를 할당합니다. 결과적으로 모든 프로젝트는 모든 유동 IP 서브넷의 유동 IP를 사용할 수 있습니다. 특정 프로젝트의 할당량을 사용하여 이 동작을 관리할 수 있습니다. 예를 들어 Project C 및 ProjectB의 할당량을 0 으로 설정하는 동안 ProjectA 및 ProjectB 의 기본값을 10 으로 설정할 수 있습니다.

절차

  • 외부 서브넷을 생성할 때 유동 IP 할당 풀을 정의할 수도 있습니다.

    $ openstack subnet create --no-dhcp --allocation-pool start=IP_ADDRESS,end=IP_ADDRESS --gateway IP_ADDRESS --network SUBNET_RANGE NETWORK_NAME

    서브넷 호스트에서 유동 IP 주소만 호스팅하는 경우 openstack subnet create 명령에서 --no-dhcp 옵션을 사용하여 DHCP 할당을 비활성화하는 것이 좋습니다.

    예제

    $ openstack subnet create --no-dhcp --allocation_pool start=192.168.100.20,end=192.168.100.100 --gateway 192.168.100.1 --network 192.168.100.0/24 public

검증

  • 인스턴스에 임의의 유동 IP를 할당하여 풀이 올바르게 구성되었는지 확인할 수 있습니다. (다음의 이후 링크를 참조하십시오.)

추가 리소스

5.2. 특정 유동 IP 할당

VM 인스턴스에 특정 유동 IP 주소를 할당할 수 있습니다.

절차

  • openstack server add floating ip 명령을 사용하여 인스턴스에 유동 IP 주소를 할당합니다.

    예제

    $ openstack server add floating ip prod-serv1 192.0.2.200

검증 단계

  • openstack server show 명령을 사용하여 유동 IP가 인스턴스와 연결되어 있는지 확인합니다.

    예제

    $ openstack server show prod-serv1

    샘플 출력

    +-----------------------------+------------------------------------------+
    | Field                       | Value                                    |
    +-----------------------------+------------------------------------------+
    | OS-DCF:diskConfig           | MANUAL                                   |
    | OS-EXT-AZ:availability_zone | nova                                     |
    | OS-EXT-STS:power_state      | Running                                  |
    | OS-EXT-STS:task_state       | None                                     |
    | OS-EXT-STS:vm_state         | active                                   |
    | OS-SRV-USG:launched_at      | 2021-08-11T14:45:37.000000               |
    | OS-SRV-USG:terminated_at    | None                                     |
    | accessIPv4                  |                                          |
    | accessIPv6                  |                                          |
    | addresses                   | public=198.51.100.56,192.0.2.200         |
    |                             |                                          |
    | config_drive                |                                          |
    | created                     | 2021-08-11T14:44:54Z                     |
    | flavor                      | review-ephemeral                         |
    |                             | (8130dd45-78f6-44dc-8173-4d6426b8e520)   |
    | hostId                      | 2308c8d8f60ed5394b1525122fb5bf8ea55c78b8 |
    |                             | 0ec6157eca4488c9                         |
    | id                          | aef3ca09-887d-4d20-872d-1d1b49081958     |
    | image                       | rhel8                                    |
    |                             | (20724bfe-93a9-4341-a5a3-78b37b3a5dfb)   |
    | key_name                    | example-keypair                          |
    | name                        | prod-serv1                               |
    | progress                    | 0                                        |
    | project_id                  | bd7a8c4a19424cf09a82627566b434fa         |
    | properties                  |                                          |
    | security_groups             | name='default'                           |
    | status                      | ACTIVE                                   |
    | updated                     | 2021-08-11T14:45:37Z                     |
    | user_id                     | 4b7e19a0d723310fd92911eb2fe59743a3a5cd32 |
    |                             | 45f76ffced91096196f646b5                 |
    | volumes_attached            |                                          |
    +-----------------------------+------------------------------------------+

추가 리소스

5.3. 고급 네트워크 생성

관리자 보기에서 대시 보드에 네트워크를 만들 때 관리자가 고급 네트워크 옵션을 사용할 수 있습니다. 이러한 옵션을 사용하여 프로젝트를 지정하고 사용하려는 네트워크 유형을 정의합니다.

절차

  1. 대시보드에서 Admin > Networks > Create Network > Project 를 선택합니다.
  2. 프로젝트 드롭다운 목록을 사용하여 새 네트워크를 호스팅할 프로젝트를 선택합니다.
  3. 공급자 네트워크 유형에서 옵션을 검토합니다.

    • 로컬 - 트래픽은 로컬 Compute 호스트에 남아 있으며 외부 네트워크와 효과적으로 격리됩니다.
    • 플랫 - 트래픽은 단일 네트워크에 남아 있으며 호스트와 공유할 수도 있습니다. VLAN 태그 지정 또는 기타 네트워크 분리가 발생하지 않습니다.
    • VLAN - 실제 네트워크에 있는 VLAN에 해당하는 VLAN ID를 사용하여 네트워크를 생성합니다. 이 옵션을 사용하면 인스턴스가 동일한 계층 2 VLAN의 시스템과 통신할 수 있습니다.
    • GRE - 인스턴스 간 개인 통신을 위해 여러 노드에 걸쳐 있는 네트워크 오버레이를 사용합니다. 오버레이를 전송하는 트래픽은 라우팅되어야 합니다.
    • VXLAN - GRE와 유사하게, 네트워크 오버레이를 사용하여 인스턴스 간 개인 통신을 위해 여러 노드를 확장합니다. 오버레이를 전송하는 트래픽은 라우팅되어야 합니다.
  4. 네트워크 생성을 클릭합니다.

    Project(프로젝트) Network Topology(네트워크 토폴로지)를 검토하여 네트워크가 성공적으로 생성되었는지 확인합니다.

5.4. 임의의 유동 IP 할당

외부 IP 주소 풀에서 VM 인스턴스에 유동 IP 주소를 동적으로 할당할 수 있습니다.

사전 요구 사항

절차

  1. 다음 명령을 입력하여 풀에서 유동 IP 주소를 할당합니다. 이 예에서 네트워크의 이름은 public 입니다.

    예제

    $ openstack floating ip create public

    샘플 출력

    다음 예에서 새로 할당된 유동 IP는 192.0.2.200 입니다. 인스턴스에 할당할 수 있습니다.

    +---------------------+--------------------------------------------------+
    | Field               | Value                                            |
    +---------------------+--------------------------------------------------+
    | fixed_ip_address    | None                                             |
    | floating_ip_address | 192.0.2.200                                      |
    | floating_network_id | f0dcc603-f693-4258-a940-0a31fd4b80d9             |
    | id                  | 6352284c-c5df-4792-b168-e6f6348e2620             |
    | port_id             | None                                             |
    | router_id           | None                                             |
    | status              | ACTIVE                                           |
    +---------------------+--------------------------------------------------+
  2. 다음 명령을 입력하여 인스턴스를 찾습니다.

    $ openstack server list

    샘플 출력

    +-------------+-------------+--------+-------------+-------+-------------+
    | ID          | Name        | Status | Networks    | Image | Flavor      |
    +-------------+-------------+--------+-------------+-------+-------------+
    | aef3ca09-88 | prod-serv1  | ACTIVE | public=198. | rhel8 | review-     |
    | 7d-4d20-872 |             |        | 51.100.56   |       | ephemeral   |
    | d-1d1b49081 |             |        |             |       |             |
    | 958         |             |        |             |       |             |
    |             |             |        |             |       |             |
    +-------------+-------------+--------+-------------+-------+-------------+

  3. 인스턴스 이름 또는 ID를 유동 IP와 연결합니다.

    예제

    $ openstack server add floating ip prod-serv1 192.0.2.200

검증 단계

  • 다음 명령을 입력하여 유동 IP가 인스턴스와 연결되어 있는지 확인합니다.

    예제

    $ openstack server show prod-serv1

    샘플 출력

    +-----------------------------+------------------------------------------+
    | Field                       | Value                                    |
    +-----------------------------+------------------------------------------+
    | OS-DCF:diskConfig           | MANUAL                                   |
    | OS-EXT-AZ:availability_zone | nova                                     |
    | OS-EXT-STS:power_state      | Running                                  |
    | OS-EXT-STS:task_state       | None                                     |
    | OS-EXT-STS:vm_state         | active                                   |
    | OS-SRV-USG:launched_at      | 2021-08-11T14:45:37.000000               |
    | OS-SRV-USG:terminated_at    | None                                     |
    | accessIPv4                  |                                          |
    | accessIPv6                  |                                          |
    | addresses                   | public=198.51.100.56,192.0.2.200         |
    |                             |                                          |
    | config_drive                |                                          |
    | created                     | 2021-08-11T14:44:54Z                     |
    | flavor                      | review-ephemeral                         |
    |                             | (8130dd45-78f6-44dc-8173-4d6426b8e520)   |
    | hostId                      | 2308c8d8f60ed5394b1525122fb5bf8ea55c78b8 |
    |                             | 0ec6157eca4488c9                         |
    | id                          | aef3ca09-887d-4d20-872d-1d1b49081958     |
    | image                       | rhel8                                    |
    |                             | (20724bfe-93a9-4341-a5a3-78b37b3a5dfb)   |
    | key_name                    | example-keypair                          |
    | name                        | prod-serv1                               |
    | progress                    | 0                                        |
    | project_id                  | bd7a8c4a19424cf09a82627566b434fa         |
    | properties                  |                                          |
    | security_groups             | name='default'                           |
    | status                      | ACTIVE                                   |
    | updated                     | 2021-08-11T14:45:37Z                     |
    | user_id                     | 4b7e19a0d723310fd92911eb2fe59743a3a5cd32 |
    |                             | 45f76ffced91096196f646b5                 |
    | volumes_attached            |                                          |
    +-----------------------------+------------------------------------------+

추가 리소스

5.5. 여러 유동 IP 풀 생성

OpenStack Networking은 각 L3 에이전트에 대해 하나의 유동 IP 풀을 지원합니다. 따라서 추가 유동 IP 풀을 생성하려면 L3 에이전트를 확장해야 합니다.

절차

  • 사용자 환경의 L3 에이전트 한 개에 대해 /var/lib/config-data/puppet-generated/neutron/neutron.conf 속성 handle_internal_only_routersTrue 로 설정되어 있는지 확인합니다. 이 옵션은 외부 라우터가 아닌 라우터만 관리하도록 L3 에이전트를 구성합니다.

5.6. 물리적 네트워크 브리징

가상 네트워크를 물리적 네트워크에 연결하여 가상 인스턴스에 대한 연결을 활성화합니다.

이 절차에서는 예제 물리 인터페이스인 eth0 이 브리지 br-ex; 가상 브리지는 실제 네트워크와 모든 가상 네트워크 간의 중개자 역할을 합니다.

결과적으로 모든 트래픽 traversing eth0 은 구성된 Open vSwitch를 사용하여 인스턴스에 도달합니다.

물리적 NIC를 가상 Open vSwitch 브리지에 매핑하려면 다음 단계를 완료합니다.

절차

  1. 텍스트 편집기에서 /etc/sysconfig/network-scripts/ifcfg-eth0 을 열고 사이트에 있는 네트워크에 적합한 값으로 다음 매개 변수를 업데이트합니다.

    • IPADDR
    • 넷마스크 게이트웨이
    • DNS1 (이름 서버)

      예를 들면 다음과 같습니다.

      # vi /etc/sysconfig/network-scripts/ifcfg-eth0
      DEVICE=eth0
      TYPE=OVSPort
      DEVICETYPE=ovs
      OVS_BRIDGE=br-ex
      ONBOOT=yes
  2. 텍스트 편집기에서 /etc/sysconfig/network-scripts/ifcfg-br-ex 를 열고 이전에 eth0에 할당된 IP 주소 값으로 가상 브리지 매개 변수를 업데이트합니다.

    # vi /etc/sysconfig/network-scripts/ifcfg-br-ex
    DEVICE=br-ex
    DEVICETYPE=ovs
    TYPE=OVSBridge
    BOOTPROTO=static
    IPADDR=192.168.120.10
    NETMASK=255.255.255.0
    GATEWAY=192.168.120.1
    DNS1=192.168.120.1
    ONBOOT=yes

    이제 인스턴스에 유동 IP 주소를 할당하고 물리적 네트워크에서 사용할 수 있도록 할 수 있습니다.

추가 리소스

5.7. 인터페이스 추가

인터페이스를 사용하여 라우터와 서브넷을 상호 연결할 수 있으므로 라우터에서 인스턴스가 중간 서브넷 외부의 대상으로 보내는 모든 트래픽을 보낼 수 있습니다.

라우터 인터페이스를 추가하고 새 인터페이스를 서브넷에 연결하려면 다음 단계를 완료합니다.

참고

이 절차에서는 네트워크 토폴로지 기능을 사용합니다. 이 기능을 사용하면 네트워크 관리 작업을 수행하는 동안 모든 가상 라우터 및 네트워크를 그래픽으로 표현할 수 있습니다.

  1. 대시보드에서 프로젝트 > 네트워크 > 네트워크 토폴로지 를 선택합니다.
  2. 관리하려는 라우터를 찾고 마우스를 올려 놓은 다음 인터페이스 추가 를 클릭합니다.
  3. 라우터에 연결할 서브넷을 지정합니다.

    IP 주소를 지정할 수도 있습니다. 주소는 이 인터페이스에 대한 ping이 정상적으로 라우팅되었음을 나타내기 때문에 테스트 및 문제 해결에 유용합니다.

  4. 인터페이스 추가를 클릭합니다.

    네트워크 토폴로지 다이어그램은 라우터와 서브넷 간 새 인터페이스 연결을 반영하도록 자동으로 업데이트됩니다.

5.8. 인터페이스 삭제

서브넷 트래픽을 보내는 데 더 이상 라우터가 필요하지 않은 경우 서브넷에 대한 인터페이스를 제거할 수 있습니다.

인터페이스를 삭제하려면 다음 단계를 완료합니다.

  1. 대시보드에서 Project > Network >라우터 를 선택합니다.
  2. 삭제할 인터페이스를 호스팅하는 라우터의 이름을 클릭합니다.
  3. 인터페이스 유형(내부 인터페이스)을 선택하고 Delete Interfaces (인터페이스 삭제)를 클릭합니다.

6장. 네트워크 문제 해결

Red Hat OpenStack Platform의 네트워크 연결 문제 해결의 진단 프로세스는 물리적 네트워크의 진단 프로세스와 유사합니다. VLAN을 사용하는 경우 가상 인프라를 임의의 별도의 환경이 아닌 실제 네트워크의 트렁크 확장으로 간주할 수 있습니다. ML2/OVS 네트워크와 기본값인 ML2/OVN 네트워크 문제 해결에는 몇 가지 차이점이 있습니다.

6.1. 기본 ping 테스트

ping 명령은 네트워크 연결 문제를 분석하는 데 유용한 툴입니다. 결과는 네트워크 연결의 기본 지표 역할을 하지만 실제 애플리케이션 트래픽을 차단하는 방화벽과 같은 모든 연결 문제는 제외되지 않을 수 있습니다. ping 명령은 트래픽을 특정 대상으로 전송한 다음, 시도가 성공했는지 여부를 다시 보고합니다.

참고

ping 명령은 ICMP 작업입니다. ping 을 사용하려면 ICMP 트래픽이 중간 방화벽을 통과하도록 허용해야 합니다.

ping 테스트는 시스템에서 네트워크 문제가 발생할 때 가장 유용하므로 머신이 완전히 오프라인인 것처럼 보이는 경우 VNC 관리 콘솔을 통해 명령줄에 연결해야 할 수 있습니다.

예를 들어 다음 ping test 명령은 네트워크 인프라의 여러 레이어의 유효성을 검사합니다. 이름 확인, IP 라우팅 및 네트워크 전환이 모두 올바르게 작동해야 합니다.

$ ping www.example.com

PING e1890.b.akamaiedge.net (125.56.247.214) 56(84) bytes of data.
64 bytes from a125-56.247-214.deploy.akamaitechnologies.com (125.56.247.214): icmp_seq=1 ttl=54 time=13.4 ms
64 bytes from a125-56.247-214.deploy.akamaitechnologies.com (125.56.247.214): icmp_seq=2 ttl=54 time=13.5 ms
64 bytes from a125-56.247-214.deploy.akamaitechnologies.com (125.56.247.214): icmp_seq=3 ttl=54 time=13.4 ms
^C

Ctrl-c를 사용하여 ping 명령을 종료할 수 있으며 그 후에는 결과에 대한 요약이 표시됩니다. 0%의 패킷 손실은 연결이 안정되었고 시간이 초과되었음을 나타냅니다.

--- e1890.b.akamaiedge.net ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 13.461/13.498/13.541/0.100 ms

테스트 대상에 따라 ping 테스트 결과가 매우 공개될 수 있습니다. 예를 들어 다음 다이어그램 VM1에는 연결 문제가 있습니다. 가능한 목적지는 파란색으로 번호가 매겨져 있으며 성공 또는 실패한 결과에서 도출된 결론이 표시됩니다.

샘플 네트워크
  1. 인터넷 - 일반적인 첫 번째 단계는 www.example.com과 같은 인터넷 위치로 ping 테스트를 보내는 것입니다.

    • 성공: 이 테스트는 컴퓨터와 인터넷 간의 모든 다양한 네트워크 포인트가 올바르게 작동하고 있음을 나타냅니다. 여기에는 가상 및 물리적 네트워크 인프라가 포함됩니다.
    • 실패: 멀리 있는 인터넷 위치로의 ping 테스트가 실패하는 방법은 여러 가지가 있습니다. 네트워크의 다른 시스템이 인터넷을 성공적으로 ping할 수 있는 경우 인터넷 연결이 작동하고 로컬 시스템 구성 내에 문제가 있을 수 있음을 증명합니다.
  2. 물리적 라우터 - 네트워크 관리자가 외부 대상으로 트래픽을 전달하도록 지정하는 라우터 인터페이스입니다.

    • 성공: 실제 라우터에 대한 ping 테스트에서는 로컬 네트워크와 기본 스위치가 작동하는지 확인할 수 있습니다. 이러한 패킷은 라우터를 통과하지 않으므로 기본 게이트웨이에 라우팅 문제가 있는지 여부를 증명하지 않습니다.
    • 실패: 이는 문제가 VM1과 기본 게이트웨이 사이에 있음을 나타냅니다. router/switches가 다운되었거나 잘못된 기본 게이트웨이를 사용할 수 있습니다. 다른 서버에서 올바르게 작동하는 구성을 비교합니다. 로컬 네트워크에서 다른 서버를 ping합니다.
  3. Neutron 라우터 - Red Hat OpenStack Platform이 가상 머신의 트래픽을 보내는 데 사용하는 가상 SDN(소프트웨어 정의 네트워킹) 라우터입니다.

    • 성공: 방화벽은 ICMP 트래픽을 허용하고, Networking 노드는 온라인입니다.
    • 실패: 인스턴스의 보안 그룹에서 ICMP 트래픽이 허용되는지 확인합니다. Networking 노드가 온라인 상태인지 확인하고 필요한 서비스가 모두 실행 중인지 확인하고 L3 에이전트 로그(/var/log/neutron/l3-agent.log)를 검토합니다.
  4. 물리적 스위치 - 물리적 스위치는 동일한 물리적 네트워크의 노드 간 트래픽을 관리합니다.

    • 성공: VM에서 물리적 스위치로 전송된 트래픽은 가상 네트워크 인프라를 통과해야 하며 이 세그먼트가 올바르게 작동하고 있음을 나타냅니다.
    • 실패: 필요한 VLAN을 트렁크하도록 물리적 스위치 포트가 구성되어 있는지 확인합니다.
  5. VM2 - 동일한 컴퓨팅 노드의 동일한 서브넷에서 VM을 ping합니다.

    • 성공: VM1의 NIC 드라이버 및 기본 IP 구성이 작동합니다.
    • 실패: VM1의 네트워크 구성을 확인합니다. 또는 VM2의 방화벽은 단순히 ping 트래픽을 차단하는 것일 수 있습니다. 또한 가상 전환 구성을 확인하고 Open vSwitch 로그 파일을 검토합니다.

6.2. 현재 포트 상태 보기

기본 문제 해결 작업은 라우터에 연결된 모든 포트의 인벤토리를 만들고 포트 상태(DOWN 또는ECDHE)를 결정하는 것입니다.

절차

  1. r1 이라는 라우터에 연결된 모든 포트를 보려면 다음 명령을 실행합니다.

    #  openstack port list --router r1

    샘플 출력

    +--------------------------------------+------+-------------------+--------------------------------------------------------------------------------------+
    | id                                   | name | mac_address       | fixed_ips                                                                            |
    +--------------------------------------+------+-------------------+--------------------------------------------------------------------------------------+
    | b58d26f0-cc03-43c1-ab23-ccdb1018252a |      | fa:16:3e:94:a7:df | {"subnet_id": "a592fdba-babd-48e0-96e8-2dd9117614d3", "ip_address": "192.168.200.1"} |
    | c45e998d-98a1-4b23-bb41-5d24797a12a4 |      | fa:16:3e:ee:6a:f7 | {"subnet_id": "43f8f625-c773-4f18-a691-fd4ebfb3be54", "ip_address": "172.24.4.225"}  |
    +--------------------------------------+------+-------------------+--------------------------------------------------------------------------------------+

  2. 각 포트의 세부 정보를 보려면 다음 명령을 실행합니다. 보려는 포트의 포트 ID를 포함합니다. 결과에는 다음 예제에 표시된 포트 상태가 NoExecute 상태가 됩니다.

    # openstack port show b58d26f0-cc03-43c1-ab23-ccdb1018252a

    샘플 출력

    +-----------------------+--------------------------------------------------------------------------------------+
    | Field                 | Value                                                                                |
    +-----------------------+--------------------------------------------------------------------------------------+
    | admin_state_up        | True                                                                                 |
    | allowed_address_pairs |                                                                                      |
    | binding:host_id       | node.example.com                                                      |
    | binding:profile       | {}                                                                                   |
    | binding:vif_details   | {"port_filter": true, "ovs_hybrid_plug": true}                                       |
    | binding:vif_type      | ovs                                                                                  |
    | binding:vnic_type     | normal                                                                               |
    | device_id             | 49c6ebdc-0e62-49ad-a9ca-58cea464472f                                                 |
    | device_owner          | network:router_interface                                                             |
    | extra_dhcp_opts       |                                                                                      |
    | fixed_ips             | {"subnet_id": "a592fdba-babd-48e0-96e8-2dd9117614d3", "ip_address": "192.168.200.1"} |
    | id                    | b58d26f0-cc03-43c1-ab23-ccdb1018252a                                                 |
    | mac_address           | fa:16:3e:94:a7:df                                                                    |
    | name                  |                                                                                      |
    | network_id            | 63c24160-47ac-4140-903d-8f9a670b0ca4                                                 |
    | security_groups       |                                                                                      |
    | status                | ACTIVE                                                                               |
    | tenant_id             | d588d1112e0f496fb6cac22f9be45d49                                                     |
    +-----------------------+--------------------------------------------------------------------------------------+

  3. 각 포트에 대해 2단계를 수행하여 상태를 확인합니다.

6.3. VLAN 공급자 네트워크에 대한 연결 문제 해결

OpenStack Networking은 VLAN 네트워크를 SDN 스위치로 트렁크할 수 있습니다. VLAN 태그 지정된 공급자 네트워크를 지원하므로 가상 인스턴스가 실제 네트워크의 서버 서브넷과 통합할 수 있습니다.

절차

  1. ping <gateway-IP-address> 를 사용하여 게이트웨이를 ping합니다.

    다음 명령을 사용하여 네트워크를 생성하는 다음 예제를 고려하십시오.

    # openstack network create --provider-network-type vlan --provider-physical-network phy-eno1 --provider-segment 120 provider
    # openstack subnet create --no-dhcp --allocation-pool start=192.168.120.1,end=192.168.120.153 --gateway 192.168.120.254 --network  provider public_subnet

    이 예에서 게이트웨이 IP 주소는 192.168.120.254 입니다.

    $ ping 192.168.120.254
  2. ping이 실패하면 다음을 수행합니다.

    1. 연결된 VLAN에 대한 네트워크 흐름이 있는지 확인합니다.

      VLAN ID가 설정되지 않았을 수 있습니다. 이 예에서 OpenStack Networking은 VLAN 120을 공급자 네트워크로 트렁크하도록 구성되어 있습니다. 1단계의 예에서 --provider:segmentation_id=120 을 참조하십시오.)

    2. ovs-ofctl dump-flows <bridge-name> 명령을 사용하여 브리지 인터페이스에서 VLAN 흐름을 확인합니다.

      이 예에서 브리지 이름은 br-ex 입니다.

      # ovs-ofctl dump-flows br-ex
      
       NXST_FLOW reply (xid=0x4):
        cookie=0x0, duration=987.521s, table=0, n_packets=67897, n_bytes=14065247, idle_age=0, priority=1 actions=NORMAL
        cookie=0x0, duration=986.979s, table=0, n_packets=8, n_bytes=648, idle_age=977, priority=2,in_port=12 actions=drop

6.4. VLAN 구성 및 로그 파일 검토

배포의 유효성을 검사하거나 문제를 해결하려면 다음을 수행할 수 있습니다.

  • RHOSP(Red Hat Openstack Platform) 네트워킹 서비스(neutron) 에이전트의 등록 및 상태를 확인합니다.
  • VLAN 범위와 같은 네트워크 구성 값을 검증합니다.

절차

  1. openstack network agent list 명령을 사용하여 RHOSP Networking 서비스 에이전트가 올바른 호스트 이름으로 작동 및 등록되어 있는지 확인합니다.

    (overcloud)[stack@undercloud~]$ openstack network agent list
    +--------------------------------------+--------------------+-----------------------+-------+----------------+
    | id                                   | agent_type         | host                  | alive | admin_state_up |
    +--------------------------------------+--------------------+-----------------------+-------+----------------+
    | a08397a8-6600-437d-9013-b2c5b3730c0c | Metadata agent     | rhelosp.example.com   | :-)   | True           |
    | a5153cd2-5881-4fc8-b0ad-be0c97734e6a | L3 agent           | rhelosp.example.com   | :-)   | True           |
    | b54f0be7-c555-43da-ad19-5593a075ddf0 | DHCP agent         | rhelosp.example.com   | :-)   | True           |
    | d2be3cb0-4010-4458-b459-c5eb0d4d354b | Open vSwitch agent | rhelosp.example.com   | :-)   | True           |
    +--------------------------------------+--------------------+-----------------------+-------+----------------+
  2. /var/log/containers/neutron/openvswitch-agent.log 를 검토합니다. 생성 프로세스에서 ovs-ofctl 명령을 사용하여 VLAN 트렁크를 구성했는지 확인합니다.
  3. /etc/neutron/l3_agent.ini 파일에서 external_network_bridge 를 검증합니다. external_network_bridge 매개변수에 하드 코딩된 값이 있는 경우 L3-agent와 함께 공급자 네트워크를 사용할 수 없으며 필요한 흐름을 생성할 수 없습니다. external_network_bridge 값은 'external_network_bridge = "" ' 형식이어야 합니다.
  4. /etc/neutron/plugin.ini 파일에서 network_vlan_ranges 값을 확인합니다. 공급자 네트워크의 경우 숫자 VLAN ID를 지정하지 마십시오. VLAN isolated 프로젝트 네트워크를 사용하는 경우에만 ID를 지정합니다.
  5. OVS 에이전트 구성 파일 브리지 매핑 을 확인하고, Restic - eno1 에 매핑된 브리지가 있으며 eno1 에 올바르게 연결되어 있는지 확인합니다.

6.5. ML2/OVN 네임스페이스 내에서 기본 ICMP 테스트 수행

기본 문제 해결 단계에서는 동일한 계층 2 네트워크에 있는 OVN 메타데이터 인터페이스에서 인스턴스를 ping할 수 있습니다.

사전 요구 사항

  • RHOSP 배포: Networking 서비스(neutron) 기본 메커니즘 드라이버인 ML2/OVN.

절차

  1. Red Hat OpenStack Platform 인증 정보를 사용하여 오버클라우드에 로그인합니다.
  2. openstack server list 명령을 실행하여 VM 인스턴스의 이름을 가져옵니다.
  3. openstack server show 명령을 실행하여 인스턴스가 실행 중인 컴퓨팅 노드를 확인합니다.

    예제

    $ openstack server show my_instance -c OS-EXT-SRV-ATTR:host \
    -c addresses

    샘플 출력

    +----------------------+-------------------------------------------------+
    | Field                | Value                                           |
    +----------------------+-------------------------------------------------+
    | OS-EXT-SRV-ATTR:host | compute0.overcloud.example.com                  |
    | addresses            | finance-network1=192.0.2.2; provider-           |
    |                      | storage=198.51.100.13                           |
    +----------------------+-------------------------------------------------+

  4. 컴퓨팅 노드 호스트에 로그인합니다.

    예제

    $ ssh tripleo-admin@compute0.example.com

  5. ip netns list 명령을 실행하여 OVN 메타데이터 네임스페이스를 확인합니다.

    샘플 출력

    ovnmeta-07384836-6ab1-4539-b23a-c581cf072011 (id: 1)
    ovnmeta-df9c28ea-c93a-4a60-b913-1e611d6f15aa (id: 0)

  6. metadata 네임스페이스를 사용하여 ip netns exec 명령을 실행하여 연결된 네트워크를 ping합니다.

    예제

    $ sudo ip netns exec ovnmeta-df9c28ea-c93a-4a60-b913-1e611d6f15aa \
    ping 192.0.2.2

    샘플 출력

    PING 192.0.2.2 (192.0.2.2) 56(84) bytes of data.
    64 bytes from 192.0.2.2: icmp_seq=1 ttl=64 time=0.470 ms
    64 bytes from 192.0.2.2: icmp_seq=2 ttl=64 time=0.483 ms
    64 bytes from 192.0.2.2: icmp_seq=3 ttl=64 time=0.183 ms
    64 bytes from 192.0.2.2: icmp_seq=4 ttl=64 time=0.296 ms
    64 bytes from 192.0.2.2: icmp_seq=5 ttl=64 time=0.307 ms
    ^C
    --- 192.0.2.2 ping statistics ---
    5 packets transmitted, 5 received, 0% packet loss, time 122ms
    rtt min/avg/max/mdev = 0.183/0.347/0.483/0.116 ms

추가 리소스

6.6. 프로젝트 네트워크 문제 해결(ML2/OVS)

RHOSP(Red Hat Openstack Platform) ML2/OVS 네트워크에서는 프로젝트가 서로 간섭하지 않고 네트워크를 구성할 수 있도록 모든 프로젝트 트래픽이 네트워크 네임스페이스에 포함됩니다. 예를 들어 네트워크 네임스페이스를 사용하면 다른 프로젝트가 서로 간섭하지 않고 동일한 서브넷 범위 192.168.1.1/24를 보유할 수 있습니다.

사전 요구 사항

  • RHOSP 배포: Networking 서비스(neutron) 기본 메커니즘 드라이버로 ML2/OVS를 사용합니다.

절차

  1. openstack network list 명령을 사용하여 모든 프로젝트 네트워크를 나열하여 네트워크가 포함된 네트워크 네임스페이스를 확인합니다.

    $ openstack network list

    이 출력에서 웹 서버 네트워크의 ID(9cb32fe0-d7fb-432c-b116-f483c6497b08 )에 유의하십시오. 이 명령은 네트워크 네임스페이스에 네트워크 ID를 추가하여 다음 단계에서 네임스페이스를 식별할 수 있습니다.

    샘플 출력

    +--------------------------------------+-------------+-------------------------------------------------------+
    | id                                   | name        | subnets                                               |
    +--------------------------------------+-------------+-------------------------------------------------------+
    | 9cb32fe0-d7fb-432c-b116-f483c6497b08 | web-servers | 453d6769-fcde-4796-a205-66ee01680bba 192.168.212.0/24 |
    | a0cc8cdd-575f-4788-a3e3-5df8c6d0dd81 | private     | c1e58160-707f-44a7-bf94-8694f29e74d3 10.0.0.0/24      |
    | baadd774-87e9-4e97-a055-326bb422b29b | private     | 340c58e1-7fe7-4cf2-96a7-96a0a4ff3231 192.168.200.0/24 |
    | 24ba3a36-5645-4f46-be47-f6af2a7d8af2 | public      | 35f3d2cb-6e4b-4527-a932-952a395c4bb3 172.24.4.224/28  |
    +--------------------------------------+-------------+-------------------------------------------------------+

  2. ip netns list 명령을 사용하여 모든 네트워크 네임스페이스를 나열합니다.

    # ip netns list

    출력에는 웹 서버 네트워크 ID와 일치하는 네임스페이스가 포함되어 있습니다.

    이 출력에서 네임스페이스는 qdhcp-9cb32fe0-d7fb-432c-b116-f483c6497b08 입니다.

    샘플 출력

    qdhcp-9cb32fe0-d7fb-432c-b116-f483c6497b08
    qrouter-31680a1c-9b3e-4906-bd69-cb39ed5faa01
    qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b
    qdhcp-a0cc8cdd-575f-4788-a3e3-5df8c6d0dd81
    qrouter-e9281608-52a6-4576-86a6-92955df46f56

  3. 네임스페이스 내에서 명령을 실행하고 ip netns exec <namespace>로 문제 해결 명령 접두사를 지정하여 웹 서버 네트워크의 구성을 검사합니다.

    이 예에서는 route -n 명령이 사용됩니다.

    예제

    # ip netns exec qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b route -n

    샘플 출력

    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    0.0.0.0         172.24.4.225    0.0.0.0         UG    0      0        0 qg-8d128f89-87
    172.24.4.224    0.0.0.0         255.255.255.240 U     0      0        0 qg-8d128f89-87
    192.168.200.0   0.0.0.0         255.255.255.0   U     0      0        0 qr-8efd6357-96

6.7. 네임스페이스 내에서 고급 ICMP 테스트 수행(ML2/OVS)

tcpdumpping 명령의 조합을 사용하여 RHOSP(Red Hat Openstack Platform) ML2/OVS 네트워크의 문제를 해결할 수 있습니다.

사전 요구 사항

  • RHOSP 배포: Networking 서비스(neutron) 기본 메커니즘 드라이버로 ML2/OVS를 사용합니다.

절차

  1. tcpdump 명령을 사용하여 ICMP 트래픽을 캡처합니다.

    예제

    # ip netns exec qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b tcpdump -qnntpi any icmp

  2. 별도의 명령줄 창에서 외부 네트워크에 대한 ping 테스트를 수행합니다.

    예제

    # ip netns exec qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b ping www.example.com

  3. tcpdump 세션을 실행하는 터미널에서 ping 테스트의 세부 결과를 관찰합니다.

    샘플 출력

    tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
    IP (tos 0xc0, ttl 64, id 55447, offset 0, flags [none], proto ICMP (1), length 88)
        172.24.4.228 > 172.24.4.228: ICMP host 192.168.200.20 unreachable, length 68
    	IP (tos 0x0, ttl 64, id 22976, offset 0, flags [DF], proto UDP (17), length 60)
        172.24.4.228.40278 > 192.168.200.21: [bad udp cksum 0xfa7b -> 0xe235!] UDP, length 32

참고

트래픽의 tcpdump 분석을 수행하면 VM 인스턴스가 아닌 라우터 인터페이스에 응답하는 패킷이 표시됩니다. 이 동작은 qrouter 가 반환 패킷에서 DNAT(Destination Network Address Translation)를 수행하므로 예상되는 동작입니다.

6.8. OVN 문제 해결 명령의 별칭 생성

ovn_controller 컨테이너에서 ovn-nbctl show 와 같은 OVN 명령을 실행합니다. 컨테이너는 컨트롤러 노드 및 컴퓨팅 노드에서 실행됩니다. 명령에 대한 액세스를 단순화하려면 별칭을 정의하는 스크립트를 생성하고 소싱합니다.

사전 요구 사항

  • Red Hat OpenStack Platform은 ML2/OVN을 기본 메커니즘 드라이버로 사용한 배포입니다.

절차

  1. OVN 컨테이너에 액세스하는 데 필요한 권한이 있는 사용자로 컨트롤러 호스트에 로그인합니다.

    예제

    $ ssh tripleo-admin@controller-0.ctlplane

  2. 실행하려는 ovn 명령이 포함된 쉘 스크립트 파일을 생성합니다.

    예제

    vi ~/bin/ovn-alias.sh

  3. ovn 명령을 추가하고 스크립트 파일을 저장합니다.

    예제

    이 예제에서는 ovn-sbctl,ovn-nbctl, ovn-trace 명령이 별칭 파일에 추가되었습니다.

    REMOTE_IP=$(sudo ovs-vsctl get open . external_ids:ovn-remote)
    NBDB=$(echo $REMOTE_IP | sed 's/6642/6641/g')
    SBDB=$REMOTE_IP
    alias ovn-sbctl="sudo podman exec ovn_controller ovn-sbctl --db=$SBDB"
    alias ovn-nbctl="sudo podman exec ovn_controller ovn-nbctl --db=$NBDB"
    alias ovn-trace="sudo podman exec ovn_controller ovn-trace --db=$SBDB"
  4. Compute 호스트에서 이 절차의 단계를 반복합니다.

검증

  1. 스크립트 파일을 가져옵니다.

    예제

    # source ovn-alias.sh

  2. 명령을 실행하여 스크립트 파일이 제대로 작동하는지 확인합니다.

    예제

    # ovn-nbctl show

    샘플 출력

    switch 26ce22db-1795-41bd-b561-9827cbd81778 (neutron-f8e79863-6c58-43d0-8f7d-8ec4a423e13b) (aka internal_network)
    	port 1913c3ae-8475-4b60-a479-df7bcce8d9c8
        	addresses: ["fa:16:3e:33:c1:fc 192.168.254.76"]
    	port 1aabaee3-b944-4da2-bf0a-573215d3f3d9
        	addresses: ["fa:16:3e:16:cb:ce 192.168.254.74"]
    	port 7e000980-59f9-4a0f-b76a-4fdf4e86f27b
        	type: localport
        	addresses: ["fa:16:3e:c9:30:ed 192.168.254.2"]

추가 리소스

  • OVN-nbctl --help 명령
  • OVN-sbctl --help 명령
  • OVN-trace --help 명령

6.9. OVN 논리 흐름 모니터링

OVN은 우선 순위, 일치 및 작업이 있는 흐름 테이블인 논리 흐름을 사용합니다. 이러한 논리 흐름은 각 RHOSP(Red Hat Openstack Platform) 컴퓨팅 노드에서 실행되는 ovn-controller 에 배포됩니다. 컨트롤러 노드에서 ovn-sbctl lflow-list 명령을 사용하여 전체 논리 흐름 세트를 확인합니다.

사전 요구 사항

절차

  1. OVN 컨테이너에 액세스하는 데 필요한 권한이 있는 사용자로 컨트롤러 호스트에 로그인합니다.

    예제

    $ ssh tripleo-admin@controller-0.ctlplane

  2. OVN 데이터베이스 명령의 별칭 파일을 가져옵니다.

    자세한 내용은 6.8절. “OVN 문제 해결 명령의 별칭 생성”의 내용을 참조하십시오.

    예제

    source ~/ovn-alias.sh

  3. 논리 흐름을 확인합니다.

    $ ovn-sbctl lflow-list
  4. 출력을 검사합니다.

    샘플 출력

    Datapath: "sw0" (d7bf4a7b-e915-4502-8f9d-5995d33f5d10)  Pipeline: ingress
      table=0 (ls_in_port_sec_l2  ), priority=100  , match=(eth.src[40]), action=(drop;)
      table=0 (ls_in_port_sec_l2  ), priority=100  , match=(vlan.present), action=(drop;)
      table=0 (ls_in_port_sec_l2  ), priority=50   , match=(inport == "sw0-port1" && eth.src == {00:00:00:00:00:01}), action=(next;)
      table=0 (ls_in_port_sec_l2  ), priority=50   , match=(inport == "sw0-port2" && eth.src == {00:00:00:00:00:02}), action=(next;)
      table=1 (ls_in_port_sec_ip  ), priority=0    , match=(1), action=(next;)
      table=2 (ls_in_port_sec_nd  ), priority=90   , match=(inport == "sw0-port1" && eth.src == 00:00:00:00:00:01 && arp.sha == 00:00:00:00:00:01), action=(next;)
      table=2 (ls_in_port_sec_nd  ), priority=90   , match=(inport == "sw0-port1" && eth.src == 00:00:00:00:00:01 && ip6 && nd && ((nd.sll == 00:00:00:00:00:00 || nd.sll == 00:00:00:00:00:01) || ((nd.tll == 00:00:00:00:00:00 || nd.tll == 00:00:00:00:00:01)))), action=(next;)
      table=2 (ls_in_port_sec_nd  ), priority=90   , match=(inport == "sw0-port2" && eth.src == 00:00:00:00:00:02 && arp.sha == 00:00:00:00:00:02), action=(next;)
      table=2 (ls_in_port_sec_nd  ), priority=90   , match=(inport == "sw0-port2" && eth.src == 00:00:00:00:00:02 && ip6 && nd && ((nd.sll == 00:00:00:00:00:00 || nd.sll == 00:00:00:00:00:02) || ((nd.tll == 00:00:00:00:00:00 || nd.tll == 00:00:00:00:00:02)))), action=(next;)
      table=2 (ls_in_port_sec_nd  ), priority=80   , match=(inport == "sw0-port1" && (arp || nd)), action=(drop;)
      table=2 (ls_in_port_sec_nd  ), priority=80   , match=(inport == "sw0-port2" && (arp || nd)), action=(drop;)
      table=2 (ls_in_port_sec_nd  ), priority=0    , match=(1), action=(next;)
      table=3 (ls_in_pre_acl      ), priority=0, match=(1), action=(next;)
      table=4 (ls_in_pre_lb       ), priority=0    , match=(1), action=(next;)
      table=5 (ls_in_pre_stateful ), priority=100  , match=(reg0[0] == 1), action=(ct_next;)
      table=5 (ls_in_pre_stateful ), priority=0    , match=(1), action=(next;)
      table=6 (ls_in_acl          ), priority=0    , match=(1), action=(next;)
      table=7 (ls_in_qos_mark     ), priority=0    , match=(1), action=(next;)
      table=8 (ls_in_lb           ), priority=0    , match=(1), action=(next;)
      table=9 (ls_in_stateful     ), priority=100  , match=(reg0[1] == 1), action=(ct_commit(ct_label=0/1); next;)
      table=9 (ls_in_stateful     ), priority=100  , match=(reg0[2] == 1), action=(ct_lb;)
      table=9 (ls_in_stateful     ), priority=0    , match=(1), action=(next;)
      table=10(ls_in_arp_rsp      ), priority=0    , match=(1), action=(next;)
      table=11(ls_in_dhcp_options ), priority=0    , match=(1), action=(next;)
      table=12(ls_in_dhcp_response), priority=0    , match=(1), action=(next;)
      table=13(ls_in_l2_lkup      ), priority=100  , match=(eth.mcast), action=(outport = "_MC_flood"; output;)
      table=13(ls_in_l2_lkup      ), priority=50   , match=(eth.dst == 00:00:00:00:00:01), action=(outport = "sw0-port1"; output;)
      table=13(ls_in_l2_lkup      ), priority=50   , match=(eth.dst == 00:00:00:00:00:02), action=(outport = "sw0-port2"; output;)
    Datapath: "sw0" (d7bf4a7b-e915-4502-8f9d-5995d33f5d10)  Pipeline: egress
      table=0 (ls_out_pre_lb      ), priority=0    , match=(1), action=(next;)
      table=1 (ls_out_pre_acl     ), priority=0    , match=(1), action=(next;)
      table=2 (ls_out_pre_stateful), priority=100  , match=(reg0[0] == 1), action=(ct_next;)
      table=2 (ls_out_pre_stateful), priority=0    , match=(1), action=(next;)
      table=3 (ls_out_lb          ), priority=0    , match=(1), action=(next;)
      table=4 (ls_out_acl         ), priority=0    , match=(1), action=(next;)
      table=5 (ls_out_qos_mark    ), priority=0    , match=(1), action=(next;)
      table=6 (ls_out_stateful    ), priority=100  , match=(reg0[1] == 1), action=(ct_commit(ct_label=0/1); next;)
      table=6 (ls_out_stateful    ), priority=100  , match=(reg0[2] == 1), action=(ct_lb;)
      table=6 (ls_out_stateful    ), priority=0    , match=(1), action=(next;)
      table=7 (ls_out_port_sec_ip ), priority=0    , match=(1), action=(next;)
      table=8 (ls_out_port_sec_l2 ), priority=100  , match=(eth.mcast), action=(output;)
      table=8 (ls_out_port_sec_l2 ), priority=50   , match=(outport == "sw0-port1" && eth.dst == {00:00:00:00:00:01}), action=(output;)
      table=8 (ls_out_port_sec_l2 ), priority=50   , match=(outport == "sw0-port2" && eth.dst == {00:00:00:00:00:02}), action=(output;)

    OVN과 OpenFlow의 주요 차이점은 다음과 같습니다.

    • OVN 포트는 단일 스위치의 물리적 포트가 아닌 네트워크에 있는 논리 엔티티입니다.
    • OVN은 파이프라인의 각 테이블에 번호 외에 이름을 제공합니다. 이름은 파이프라인에서 해당 단계의 목적을 설명합니다.
    • OVN 일치 구문은 복잡한 부울 표현식을 지원합니다.
    • OVN 논리 흐름에서 지원되는 작업은 OpenFlow를 넘어 확장됩니다. OVN 논리 흐름 구문에서 DHCP와 같은 상위 수준 기능을 구현할 수 있습니다.
  5. OVN 추적을 실행합니다.

    ovn-trace 명령은 패킷이 OVN 논리 흐름을 통과하는 방법을 시뮬레이션하거나 패킷이 삭제된 이유를 결정하는 데 도움이 될 수 있습니다. 다음 매개변수와 함께 ovn-trace 명령을 제공합니다.

    DATAPATH
    시뮬레이션된 패킷이 시작되는 논리 스위치 또는 논리 라우터입니다.
    MICROFLOW

    ovn-sb 데이터베이스에서 사용하는 구문에서 시뮬레이션된 패킷입니다.

    예제

    이 예에서는 시뮬레이션된 패킷의 --minimal 출력 옵션을 표시하고 패킷이 대상에 도달하는 것을 보여줍니다.

    $ ovn-trace --minimal sw0 'inport == "sw0-port1" && eth.src == 00:00:00:00:00:01 && eth.dst == 00:00:00:00:00:02'

    샘플 출력

    #  reg14=0x1,vlan_tci=0x0000,dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:02,dl_type=0x0000
        output("sw0-port2");

    예제

    보다 상세하게는 이 동일한 시뮬레이션된 패킷에 대한 --summary 출력은 전체 실행 파이프라인을 보여줍니다.

    $ ovn-trace --summary sw0 'inport == "sw0-port1" && eth.src == 00:00:00:00:00:01 && eth.dst == 00:00:00:00:00:02'

    샘플 출력

    샘플 출력은 다음을 보여줍니다.

    • 패킷은 sw0-port1 포트에서 sw0 네트워크를 입력하고 Ingress 파이프라인을 실행합니다.
    • outport 변수는 이 패킷의 의도된 대상이 sw0-port2 임을 나타내는 sw0-port2 로 설정됩니다.
    • 수신 파이프라인의 패킷은 sw0-port2 로 설정된 outport 변수를 사용하여 sw0 의 송신 파이프라인으로 가져옵니다.
    • 출력 작업은 패킷을 sw0-port2outport 변수의 현재 값으로 출력하는 송신 파이프라인에서 실행됩니다.

      #  reg14=0x1,vlan_tci=0x0000,dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:02,dl_type=0x0000
      ingress(dp="sw0", inport="sw0-port1") {
          outport = "sw0-port2";
          output;
          egress(dp="sw0", inport="sw0-port1", outport="sw0-port2") {
              output;
              /* output to "sw0-port2", type "" */;
          };
      };

추가 리소스

6.10. OpenFlow 모니터링

ovs-ofctl dump-flows 명령을 사용하여 RHOSP(Red Hat Openstack Platform) 네트워크의 논리 스위치에서 OpenFlow 흐름을 모니터링할 수 있습니다.

사전 요구 사항

  • Networking 서비스(neutron) 기본 메커니즘 드라이버로 ML2/OVN을 사용한 RHOSP 배포.

절차

  1. OVN 컨테이너에 액세스하는 데 필요한 권한이 있는 사용자로 컨트롤러 호스트에 로그인합니다.

    예제

    $ ssh tripleo-admin@controller-0.ctlplane

  2. ovs-ofctl dump-flows 명령을 실행합니다.

    예제

    $ sudo ovs-ofctl dump-flows br-int

  3. 다음 출력과 유사한 출력을 검사합니다.

    샘플 출력

    $ ovs-ofctl dump-flows br-int
    NXST_FLOW reply (xid=0x4):
     cookie=0x0, duration=72.132s, table=0, n_packets=0, n_bytes=0, idle_age=72, priority=10,in_port=1,dl_src=00:00:00:00:00:01 actions=resubmit(,1)
     cookie=0x0, duration=60.565s, table=0, n_packets=0, n_bytes=0, idle_age=60, priority=10,in_port=2,dl_src=00:00:00:00:00:02 actions=resubmit(,1)
     cookie=0x0, duration=28.127s, table=0, n_packets=0, n_bytes=0, idle_age=28, priority=0 actions=drop
     cookie=0x0, duration=13.887s, table=1, n_packets=0, n_bytes=0, idle_age=13, priority=0,in_port=1 actions=output:2
     cookie=0x0, duration=4.023s, table=1, n_packets=0, n_bytes=0, idle_age=4, priority=0,in_port=2 actions=output:1

추가 리소스

  • OVS-ofctl --help 명령

6.11. ML2/OVN 배포 검증

RHOSP(Red Hat OpenStack Platform) 배포에서 ML2/OVN 네트워크를 검증하는 것은 테스트 네트워크 및 서브넷을 생성하고 specfic 컨테이너가 실행 중인지 확인하는 것과 같은 진단 작업을 수행하는 것으로 구성됩니다.

사전 요구 사항

절차

  1. 테스트 네트워크 및 서브넷을 만듭니다.

    NETWORK_ID=\
    $(openstack network create internal_network | awk '/\| id/ {print $4}')
    
    openstack subnet create internal_subnet \
    --network $NETWORK_ID \
    --dns-nameserver 8.8.8.8 \
    --subnet-range 192.168.254.0/24

    오류가 발생하면 다음 단계를 수행하십시오.

  2. 관련 컨테이너가 컨트롤러 호스트에서 실행 중인지 확인합니다.

    1. OVN 컨테이너에 액세스하는 데 필요한 권한이 있는 사용자로 컨트롤러 호스트에 로그인합니다.

      예제

      $ ssh tripleo-admin@controller-0.ctlplane

    2. 다음 명령을 실행합니다.

      $ sudo podman ps -a --format="{{.Names}}"|grep ovn

      다음 샘플에 표시된 대로 출력에 OVN 컨테이너가 나열되어야 합니다.

      샘플 출력

      container-puppet-ovn_controller
      ovn_cluster_north_db_server
      ovn_cluster_south_db_server
      ovn_cluster_northd
      ovn_controller

  3. 관련 컨테이너가 Compute 호스트에서 실행 중인지 확인합니다.

    1. OVN 컨테이너에 액세스하는 데 필요한 권한이 있는 사용자로 Compute 호스트에 로그인합니다.

      예제

      $ ssh tripleo-admin@compute-0.ctlplane

    2. 다음 명령을 실행합니다.

      $ sudo podman ps -a --format="{{.Names}}"|grep ovn

      다음 샘플에 표시된 대로 출력에 OVN 컨테이너가 나열되어야 합니다.

      샘플 출력

      container-puppet-ovn_controller
      ovn_metadata_agent
      ovn_controller

  4. 로그 파일에서 오류 메시지를 검사합니다.

    grep -r ERR /var/log/containers/openvswitch/ /var/log/containers/neutron/
  5. 별칭 파일을 가져와 OVN 데이터베이스 명령을 실행합니다.

    자세한 내용은 6.8절. “OVN 문제 해결 명령의 별칭 생성”의 내용을 참조하십시오.

    예제

    $ source ~/ovn-alias.sh

  6. northbound 및 southbound 데이터베이스를 쿼리하여 응답성을 확인합니다.

    # ovn-nbctl show
    # ovn-sbctl show
  7. 동일한 계층 2 네트워크에 있는 OVN 메타데이터 인터페이스에서 인스턴스를 ping합니다.

    자세한 내용은 6.5절. “ML2/OVN 네임스페이스 내에서 기본 ICMP 테스트 수행”의 내용을 참조하십시오.

  8. 지원을 받기 위해 Red Hat에 문의해야 하는 경우 이 Red Hat 솔루션에 설명된 단계를 수행하십시오. Red Hat 지원에 필요한 모든 로그를 수집하여 OpenStack 문제를 조사하는 방법.

추가 리소스

6.12. ML2/OVN의 로깅 모드 설정

추가 문제 해결 정보를 위해 ML2/OVN 로깅을 디버그 모드로 설정합니다. 추가 디버깅 정보가 필요하지 않은 경우 디스크 공간을 적게 사용하려면 info 모드로 다시 로깅을 설정합니다.

사전 요구 사항

  • Red Hat OpenStack Platform은 ML2/OVN을 기본 메커니즘 드라이버로 사용한 배포입니다.

절차

  1. OVN 컨테이너에 액세스하는 데 필요한 권한이 있는 사용자로 로깅 모드를 설정하려는 컨트롤러 또는 컴퓨팅 노드에 로그인합니다.

    예제

    $ ssh tripleo-admin@controller-0.ctlplane

  2. ML2/OVN 로깅 모드를 설정합니다.

    디버그 로깅 모드
    $ sudo podman exec -it ovn_controller ovn-appctl -t ovn-controller vlog/set dbg
    정보 로깅 모드
    $ sudo podman exec -it ovn_controller ovn-appctl -t ovn-controller vlog/set info

검증

  • ovn-controller 컨테이너 로그에 디버그 메시지가 포함되어 있는지 확인합니다.

    $ sudo grep DBG /var/log/containers/openvswitch/ovn-controller.log

    샘플 출력

    문자열이 포함된 최근 로그 메시지가 표시되어야 합니다 |DBG|:

    2022-09-29T20:52:54.638Z|00170|vconn(ovn_pinctrl0)|DBG|unix:/var/run/openvswitch/br-int.mgmt: received: OFPT_ECHO_REQUEST (OF1.5) (xid=0x0): 0 bytes of payload
    2022-09-29T20:52:54.638Z|00171|vconn(ovn_pinctrl0)|DBG|unix:/var/run/openvswitch/br-int.mgmt: sent (Success): OFPT_ECHO_REPLY (OF1.5) (xid=0x0): 0 bytes of payload
  • ovn-controller 컨테이너 로그에 다음과 유사한 문자열이 포함되어 있는지 확인합니다.

    ...received request vlog/set["info"], id=0

6.13. 에지 사이트에 등록할 수 없는 OVN 컨트롤러 수정

문제

RHOSP(Red Hat OpenStack Platform) 에지 사이트의 OVN 컨트롤러는 등록할 수 없습니다.

참고

이 오류는 이전 RHOSP 버전에서 업데이트된 RHOSP 17.0 ML2/OVN 배포에서 발생할 수 있습니다.RHOSP 16.1.7 및 이전 버전 또는 RHOSP 16.2.0.

샘플 오류

발생한 오류는 다음과 유사합니다.

2021-04-12T09:14:48.994Z|04754|ovsdb_idl|WARN|transaction error: {"details":"Transaction causes multiple rows in \"Encap\" table to have identical values (geneve and \"10.14.2.7\") for index on columns \"type\" and \"ip\".  First row, with UUID 3973cad5-eb8a-4f29-85c3-c105d861c0e0, was inserted by this transaction.  Second row, with UUID f06b71a8-4162-475b-8542-d27db3a9097a, existed in the database before this transaction and was not modified by the transaction.","error":"constraint violation"}
원인
ovn-controller 프로세스가 호스트 이름을 교체하면 다른 encap 항목이 포함된 다른 섀시 항목을 등록합니다. 자세한 내용은 BZ#1948472 에서 참조하십시오.
해결

다음 단계에 따라 문제를 해결합니다.

  1. 아직 없는 경우 이 절차의 뒷부분에서 사용할 필수 OVN 데이터베이스 명령에 대한 별칭을 생성합니다.

    자세한 내용은 OVN 문제 해결 명령의 별칭 생성을 참조하십시오.

  2. OVN 컨테이너에 액세스하는 데 필요한 권한이 있는 사용자로 컨트롤러 호스트에 로그인합니다.

    예제

    $ ssh tripleo-admin@controller-0.ctlplane

  3. /var/log/containers/openvswitch/ovn-controller.log에서 IP 주소를 가져옵니다.
  4. IP 주소가 올바른지 확인합니다.

    ovn-sbctl list encap |grep -a3 <IP address from ovn-controller.log>
  5. IP 주소가 포함된 섀시를 삭제합니다.

    ovn-sbctl chassis-del <chassis-id>
  6. Chassis_Private 표를 확인하여 섀시가 제거되었는지 확인합니다.

    ovn-sbctl find Chassis_private chassis="[]"
  7. 보고되는 항목이 있는 경우 다음 명령을 사용하여 해당 항목을 제거합니다.

    $ ovn-sbctl destroy Chassis_Private <listed_id>
  8. 다음 컨테이너를 다시 시작하십시오.

    • tripleo_ovn_controller
    • tripleo_ovn_metadata_agent

      $ sudo systemctl restart tripleo_ovn_controller
      $ sudo systemctl restart tripleo_ovn_metadata_agent

검증

  • OVN 에이전트가 실행 중인지 확인합니다.

    $ openstack network agent list -c "Agent Type" -c State -c Binary

    샘플 출력

    +------------------------------+-------+----------------------------+
    | Agent Type                   | State | Binary                     |
    +------------------------------+-------+----------------------------+
    | OVN Controller Gateway agent | UP    | ovn-controller             |
    | OVN Controller Gateway agent | UP    | ovn-controller             |
    | OVN Controller agent         | UP    | ovn-controller             |
    | OVN Metadata agent           | UP    | neutron-ovn-metadata-agent |
    | OVN Controller Gateway agent | UP    | ovn-controller             |
    +------------------------------+-------+----------------------------+

6.14. ML2/OVN 로그 파일

로그 파일은 ML2/OVN 메커니즘 드라이버의 배포 및 작업과 관련된 이벤트를 추적합니다.

표 6.1. 노드당 ML2/OVN 로그 파일

노드log경로 /var/log/containers/openvswitch...

컨트롤러, 컴퓨팅, 네트워킹

OVS northbound 데이터베이스 서버

.../ovn-controller.log

컨트롤러

OVS northbound 데이터베이스 서버

.../ovsdb-server-nb.log

컨트롤러

OVS southbound 데이터베이스 서버

.../ovsdb-server-sb.log

컨트롤러

OVN northbound 데이터베이스 서버

.../ovn-northd.log

7장. OpenStack Networking의 물리적 스위치 구성

이 장에서는 OpenStack Networking에 필요한 일반적인 물리적 스위치 구성 단계를 설명합니다. 특정 스위치에 대해 벤더별 구성이 포함되어 있습니다.

7.1. 물리적 네트워크 환경 계획

OpenStack 노드의 물리적 네트워크 어댑터는 인스턴스 트래픽, 스토리지 데이터 또는 인증 요청과 같은 다양한 유형의 네트워크 트래픽을 전달합니다. 이러한 NIC가 전달하는 트래픽 유형은 물리적 스위치에서 포트를 구성하는 방법에 영향을 미칩니다.

먼저 어떤 유형의 트래픽을 전송할 컴퓨팅 노드의 OFn을 출력할 물리적 NIC를 결정해야합니다. 그런 다음 NIC가 물리적 스위치 포트에 연결할 때 트렁크 또는 일반 트래픽을 허용하도록 스위치 포트를 구성해야 합니다.

예를 들어 다음 다이어그램은 eth0 및 eth1의 두 개의 NIC가 있는 컴퓨팅 노드를 보여줍니다. 각 NIC는 물리적 스위치의 기가비트 이더넷 포트에 연결되고, eth0 인스턴스 트래픽을 수행하고, eth1은 OpenStack 서비스에 대한 연결을 제공합니다.

그림 7.1. 네트워크 레이아웃 샘플

네트워크 레이아웃 샘플
참고

이 다이어그램에는 내결함성에 필요한 추가 중복 NIC가 포함되어 있지 않습니다.

추가 리소스

7.2. Cisco Catalyst 스위치 구성

7.2.1. 트렁크 포트 정보

OpenStack Networking을 사용하면 물리 네트워크에 이미 존재하는 VLAN에 인스턴스를 연결할 수 있습니다. 트렁크 라는 용어는 여러 VLAN이 동일한 포트를 통과할 수 있는 포트를 설명하는 데 사용됩니다. 이러한 포트를 사용하여 VLAN은 가상 스위치를 포함하여 여러 스위치에 걸쳐 있을 수 있습니다. 예를 들어 물리적 네트워크에서 VLAN110으로 태그된 트래픽이 Compute 노드에 도달하고 8021q 모듈은 태그된 트래픽을 vSwitch의 적절한 VLAN으로 보냅니다.

7.2.2. Cisco Catalyst 스위치에 대한 트렁크 포트 구성

  • Cisco IOS를 실행하는 Cisco Catalyst 스위치를 사용하는 경우 다음 구성 구문을 사용하여 VLAN 110과 111의 트래픽이 인스턴스로 통과할 수 있습니다.

    이 설정에서는 물리적 노드에 물리적 스위치의 GigabitEthernet1/0/12 인터페이스에 연결된 이더넷 케이블이 있다고 가정합니다.

    중요

    이러한 값은 다음과 같습니다. 이 예제의 값은 해당 환경과 일치하도록 변경해야 합니다. 조정 없이 이러한 값을 스위치 구성에 복사하고 붙여넣으면 예기치 않은 중단이 발생할 수 있습니다.

    interface GigabitEthernet1/0/12
      description Trunk to Compute Node
      spanning-tree portfast trunk
      switchport trunk encapsulation dot1q
      switchport mode trunk
      switchport trunk native vlan 2
      switchport trunk allowed vlan 2,110,111

    다음 목록을 사용하여 이러한 매개변수를 파악합니다.

    필드설명

    interface GigabitEthernet1/0/12

    X 노드의 NIC가 연결하는 스위치 포트입니다. GigabitEthernet1/0/12 값을 사용자 환경의 올바른 포트 값으로 교체해야 합니다. show interface 명령을 사용하여 포트 목록을 봅니다.

    Compute 노드에 대한 설명 Trunk to Compute Node

    이 인터페이스를 식별하는 데 사용할 수 있는 고유하고 설명적인 값입니다.

    spanning-tree 포트fast 트렁크

    환경에서 STP를 사용하는 경우 이 값을 설정하여 Port Fast에 이 포트가 트래픽을 트렁크하는 데 사용됩니다.

    스위치 포트 트렁크 캡슐화 dot1q

    802.1q 트렁킹 표준(ISL 대신)을 활성화합니다. 이 값은 스위치에서 지원하는 구성에 따라 다릅니다.

    스위치 포트 모드 트렁크

    이 포트를 액세스 포트가 아닌 트렁크 포트로 설정합니다. 즉 VLAN 트래픽이 가상 스위치로 통과할 수 있습니다.

    스위치 포트 트렁크 기본 vlan 2

    기본 VLAN을 설정하여 태그되지 않은(VLAN이 아닌) 트래픽을 보낼 위치를 스위치에 지시합니다.

    스위치 포트 트렁크 허용 vlan 2,110,111

    트렁크를 통해 허용되는 VLAN을 정의합니다.

7.2.3. 액세스 포트 정보

컴퓨팅 노드의 모든 NIC가 인스턴스 트래픽을 전달하는 것은 아니므로 여러 VLAN이 통과할 수 있도록 모든 NIC를 구성할 필요가 없습니다. 액세스 포트에는 VLAN이 하나만 필요하며, 관리 트래픽 또는 블록 스토리지 데이터와 같은 기타 운영 요구 사항을 충족할 수 있습니다. 이러한 포트는 일반적으로 액세스 포트라고 하며 일반적으로 트렁크 포트보다 간단한 구성이 필요합니다.

7.2.4. Cisco Catalyst 스위치에 대한 액세스 포트 구성

  • 그림 7.1. “네트워크 레이아웃 샘플” 다이어그램의 예제를 사용하여 GigabitEthernet1/0/13 (Cisco catalyst 스위치)은 eth1 의 액세스 포트로 구성됩니다.

    이 구성에서 물리적 노드에는 물리적 스위치의 GigabitEthernet1/0/12 인터페이스에 연결된 이더넷 케이블이 있습니다.

    중요

    이러한 값은 다음과 같습니다. 이 예제의 값은 해당 환경과 일치하도록 변경해야 합니다. 조정 없이 이러한 값을 스위치 구성에 복사하고 붙여넣으면 예기치 않은 중단이 발생할 수 있습니다.

    interface GigabitEthernet1/0/13
     description Access port for Compute Node
     switchport mode access
     switchport access vlan 200
     spanning-tree portfast

    이러한 설정은 아래에 설명되어 있습니다.

    필드설명

    interface GigabitEthernet1/0/13

    X 노드의 NIC가 연결하는 스위치 포트입니다. GigabitEthernet1/0/12 값을 사용자 환경의 올바른 포트 값으로 교체해야 합니다. show interface 명령을 사용하여 포트 목록을 봅니다.

    컴퓨팅 노드에 대한 설명 액세스 포트

    이 인터페이스를 식별하는 데 사용할 수 있는 고유하고 설명적인 값입니다.

    스위치 포트 모드 액세스

    이 포트를 트렁크 포트가 아닌 액세스 포트로 설정합니다.

    스위치 포트 액세스 vlan 200

    VLAN 200에서 트래픽을 허용하도록 포트를 구성합니다. 이 VLAN의 IP 주소로 컴퓨팅 노드를 구성해야 합니다.

    spanning-tree 포트fast

    STP를 사용하는 경우 이 값을 설정하여 STP에 트렁크로 초기화하지 않도록 지시하여 초기 연결 중 더 빠른 포트 핸드셰이크(예: 서버 재부팅)를 허용합니다.

7.2.5. LACP 포트 집계 정보

LACP(Link Aggregation Control Protocol)를 사용하여 여러 개의 물리적 NIC를 함께 번들하여 단일 논리 채널을 구성할 수 있습니다. 802.3ad (또는 Linux에서 본딩 모드 4)라고도 하는 LACP는 로드 밸런싱 및 내결함성을 위한 동적 본딩을 생성합니다. 물리적인 NIC와 물리적 스위치 포트 모두에서 LACP를 구성해야 합니다.

추가 리소스

7.2.6. 물리적 NIC에서 LACP 구성

물리적 NIC에서 LACP(Link Aggregation Control Protocol)를 구성할 수 있습니다.

절차

  1. /home/stack/network-environment.yaml 파일을 편집합니다.

    - type: linux_bond
      name: bond1
      mtu: 9000
      bonding_options:{get_param: BondInterfaceOvsOptions};
      members:
        - type: interface
          name: nic3
          mtu: 9000
          primary: true
        - type: interface
          name: nic4
          mtu: 9000
  2. LACP를 사용하도록 Open vSwitch 브리지를 구성합니다.

    BondInterfaceOvsOptions:
        "mode=802.3ad"

추가 리소스

7.2.7. Cisco Catalyst 스위치에 대한 LACP 구성

이 예에서 Compute 노드에는 VLAN 100을 사용하는 두 개의 NIC가 있습니다.

절차

  1. Compute 노드의 NIC를 스위치(예: 포트 12 및 13)에 물리적으로 연결합니다.
  2. LACP 포트 채널을 생성합니다.

    interface port-channel1
      switchport access vlan 100
      switchport mode access
      spanning-tree guard root
  3. 스위치 포트 12 (Gi1/0/12) 및 13 (Gi1/0/13)을 구성합니다.

    sw01# config t
    Enter configuration commands, one per line.  End with CNTL/Z.
    
    sw01(config) interface GigabitEthernet1/0/12
       switchport access vlan 100
       switchport mode access
       speed 1000
       duplex full
       channel-group 10 mode active
       channel-protocol lacp
    
    interface GigabitEthernet1/0/13
      switchport access vlan 100
      switchport mode access
      speed 1000
      duplex full
      channel-group 10 mode active
      channel-protocol lacp
  4. 새 포트 채널을 검토합니다. 결과 출력에는 멤버 포트 Gi1/0/12Gi1/0/13 이 있는 새 port-channel Po1 이 나열됩니다.

    sw01# show etherchannel summary
    <snip>
    
    Number of channel-groups in use: 1
    Number of aggregators:           1
    
    Group  Port-channel  Protocol    Ports
    ------+-------------+-----------+-----------------------------------------------
    1      Po1(SD)         LACP      Gi1/0/12(D)  Gi1/0/13(D)
    참고

    running-config를 startup-config에 복사하여 변경 사항을 적용하십시오. running-config startup-config.

7.2.8. MTU 설정 정보

특정 유형의 네트워크 트래픽에 대해 MTU 크기를 조정해야 합니다. 예를 들어, 특정 NFS 또는 iSCSI 트래픽에는 점보 프레임(9000바이트)이 필요합니다.

참고

가상 스위치를 포함하여 트래픽이 통과할 것으로 예상되는 모든 홉의 MTU 설정을 엔드 투 엔드에서 변경해야 합니다.

7.2.9. Cisco Catalyst 스위치에 대한 MTU 설정 구성

이 예제 절차의 단계를 완료하여 Cisco catalyst 3750 스위치에서 점보 프레임을 활성화합니다.

  1. 현재 MTU 설정을 확인합니다.

    sw01# show system mtu
    
    System MTU size is 1600 bytes
    System Jumbo MTU size is 1600 bytes
    System Alternate MTU size is 1600 bytes
    Routing MTU size is 1600 bytes
  2. MTU 설정은 개별 인터페이스가 아닌 3750 스위치의 스위치 전체에서 변경됩니다. 다음 명령을 실행하여 9000바이트의 점보 프레임을 사용하도록 스위치를 구성합니다. 스위치에서 이 기능을 지원하는 경우 개별 인터페이스에 대한 MTU 설정을 구성하는 것이 좋습니다.

    sw01# config t
    Enter configuration commands, one per line.  End with CNTL/Z.
    
    sw01(config)# system mtu jumbo 9000
    Changes to the system jumbo MTU will not take effect until the next reload is done
    참고

    running-config를 startup-config: copy running-config startup-config 에 복사하여 변경 사항을 저장하십시오.

  3. 스위치를 다시 로드하여 변경 사항을 적용합니다.

    중요

    스위치를 다시 로드하면 스위치에 종속된 모든 장치에 대한 네트워크가 중단됩니다. 따라서 예약된 유지 관리 기간 중에만 스위치를 다시 로드합니다.

    sw01# reload
    Proceed with reload? [confirm]
  4. 스위치가 다시 로드되면 새 점보 MTU 크기를 확인합니다.

    정확한 출력은 스위치 모델에 따라 다를 수 있습니다. 예를 들어 System MTU 는 비Gigabit 인터페이스에 적용될 수 있으며 Jumbo MTU 는 모든 기가비트 인터페이스를 설명할 수 있습니다.

    sw01# show system mtu
    
    System MTU size is 1600 bytes
    System Jumbo MTU size is 9000 bytes
    System Alternate MTU size is 1600 bytes
    Routing MTU size is 1600 bytes

7.2.10. LLDP 검색 정보

ironic-python-agent 서비스는 연결된 스위치에서 LLDP 패킷을 수신 대기합니다. 수집된 정보에는 스위치 이름, 포트 세부 정보 및 사용 가능한 VLAN이 포함될 수 있습니다. Cisco Discovery Protocol(CDP)과 유사하게 LLDP는 director 인트로스펙션 프로세스 중에 물리적 하드웨어 검색을 지원합니다.

7.2.11. Cisco Catalyst 스위치를 위한 LLDP 구성

절차

  1. lldp run 명령을 실행하여 Cisco Catalyst 스위치에서 LLDP를 전역적으로 사용하도록 설정합니다.

    sw01# config t
    Enter configuration commands, one per line.  End with CNTL/Z.
    
    sw01(config)# lldp run
  2. 모든 인접한 LLDP 호환 장치를 확인합니다.

    sw01# show lldp neighbor
    Capability codes:
        (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
        (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
    
    Device ID           Local Intf     Hold-time  Capability      Port ID
    DEP42037061562G3     Gi1/0/11       180        B,T             422037061562G3:P1
    
    Total entries displayed: 1
참고

running-config를 startup-config: copy running-config startup-config 에 복사하여 변경 사항을 저장하십시오.

7.3. Cisco Nexus 전환 구성

7.3.1. 트렁크 포트 정보

OpenStack Networking을 사용하면 물리 네트워크에 이미 존재하는 VLAN에 인스턴스를 연결할 수 있습니다. 트렁크 라는 용어는 여러 VLAN이 동일한 포트를 통과할 수 있는 포트를 설명하는 데 사용됩니다. 이러한 포트를 사용하여 VLAN은 가상 스위치를 포함하여 여러 스위치에 걸쳐 있을 수 있습니다. 예를 들어 물리적 네트워크에서 VLAN110으로 태그된 트래픽이 Compute 노드에 도달하고 8021q 모듈은 태그된 트래픽을 vSwitch의 적절한 VLAN으로 보냅니다.

7.3.2. Cisco Nexus 스위치에 대한 트렁크 포트 구성

  • Cisco Nexus를 사용하는 경우 다음 구성 구문을 사용하여 VLAN 110 및 111에 대한 트래픽이 인스턴스로 전달되도록 허용할 수 있습니다.

    이 설정에서는 물리적인 노드에 물리적 스위치의 이더넷 1/12 인터페이스에 연결된 이더넷 케이블이 있다고 가정합니다.

    중요

    이러한 값은 다음과 같습니다. 이 예제의 값은 해당 환경과 일치하도록 변경해야 합니다. 조정 없이 이러한 값을 스위치 구성에 복사하고 붙여넣으면 예기치 않은 중단이 발생할 수 있습니다.

    interface Ethernet1/12
      description Trunk to Compute Node
      switchport mode trunk
      switchport trunk allowed vlan 2,110,111
      switchport trunk native vlan 2
    end

7.3.3. 액세스 포트 정보

컴퓨팅 노드의 모든 NIC가 인스턴스 트래픽을 전달하는 것은 아니므로 여러 VLAN이 통과할 수 있도록 모든 NIC를 구성할 필요가 없습니다. 액세스 포트에는 VLAN이 하나만 필요하며, 관리 트래픽 또는 블록 스토리지 데이터와 같은 기타 운영 요구 사항을 충족할 수 있습니다. 이러한 포트는 일반적으로 액세스 포트라고 하며 일반적으로 트렁크 포트보다 간단한 구성이 필요합니다.

7.3.4. Cisco Nexus 스위치에 대한 액세스 포트 구성

절차

  • 그림 7.1. “네트워크 레이아웃 샘플” 다이어그램의 예제를 사용하여 이더넷1/13( Cisco Nexus 전환 시)은 eth1 의 액세스 포트로 구성됩니다. 이 설정에서는 물리적 노드에 물리적 스위치의 이더넷 1/13 인터페이스에 연결된 이더넷 케이블이 있다고 가정합니다.

    중요

    이러한 값은 다음과 같습니다. 이 예제의 값은 해당 환경과 일치하도록 변경해야 합니다. 조정 없이 이러한 값을 스위치 구성에 복사하고 붙여넣으면 예기치 않은 중단이 발생할 수 있습니다.

    interface Ethernet1/13
     description Access port for Compute Node
     switchport mode access
     switchport access vlan 200

7.3.5. LACP 포트 집계 정보

LACP(Link Aggregation Control Protocol)를 사용하여 여러 개의 물리적 NIC를 함께 번들하여 단일 논리 채널을 구성할 수 있습니다. 802.3ad (또는 Linux에서 본딩 모드 4)라고도 하는 LACP는 로드 밸런싱 및 내결함성을 위한 동적 본딩을 생성합니다. 물리적인 NIC와 물리적 스위치 포트 모두에서 LACP를 구성해야 합니다.

추가 리소스

7.3.6. 물리적 NIC에서 LACP 구성

물리적 NIC에서 LACP(Link Aggregation Control Protocol)를 구성할 수 있습니다.

절차

  1. /home/stack/network-environment.yaml 파일을 편집합니다.

    - type: linux_bond
      name: bond1
      mtu: 9000
      bonding_options:{get_param: BondInterfaceOvsOptions};
      members:
        - type: interface
          name: nic3
          mtu: 9000
          primary: true
        - type: interface
          name: nic4
          mtu: 9000
  2. LACP를 사용하도록 Open vSwitch 브리지를 구성합니다.

    BondInterfaceOvsOptions:
        "mode=802.3ad"

추가 리소스

7.3.7. Cisco Nexus 스위치에 대한 LACP 구성

이 예에서 Compute 노드에는 VLAN 100을 사용하는 두 개의 NIC가 있습니다.

절차

  1. Compute 노드 NIC를 스위치에 물리적으로 연결합니다(예: 포트 12 및 13).
  2. LACP가 활성화되어 있는지 확인합니다.

    (config)# show feature | include lacp
    lacp                  1         enabled
  3. 포트 1/12 및 1/13을 액세스 포트로 구성하고 채널 그룹의 구성원으로 구성합니다.

    배포에 따라 인터페이스에 액세스하는 대신 트렁크 인터페이스를 배포할 수 있습니다.

    예를 들어, Cisco UCI의 경우 NIC는 가상 인터페이스이므로 전용 액세스 포트를 구성하는 것이 좋습니다. 종종 이러한 인터페이스에는 VLAN 태그 지정 구성이 포함되어 있습니다.

    interface Ethernet1/13
     description Access port for Compute Node
     switchport mode access
     switchport access vlan 200
     channel-group 10 mode active
    
    interface Ethernet1/13
     description Access port for Compute Node
     switchport mode access
     switchport access vlan 200
     channel-group 10 mode active
참고

Cisco 스위치에서 노드를 프로비저닝하는 데 PXE를 사용하는 경우, 포트를 가져오고 서버를 부팅하기 위해 lacp grace-convergencelacp suspend-individual 옵션을 설정해야 할 수 있습니다. 자세한 내용은 Cisco 스위치 설명서를 참조하십시오.

7.3.8. MTU 설정 정보

특정 유형의 네트워크 트래픽에 대해 MTU 크기를 조정해야 합니다. 예를 들어, 특정 NFS 또는 iSCSI 트래픽에는 점보 프레임(9000바이트)이 필요합니다.

참고

가상 스위치를 포함하여 트래픽이 통과할 것으로 예상되는 모든 홉의 MTU 설정을 엔드 투 엔드에서 변경해야 합니다.

7.3.9. Cisco Nexus 7000 스위치의 MTU 설정 구성

7000 시리즈 스위치의 단일 인터페이스에 MTU 설정을 적용합니다.

절차

  • 다음 명령을 실행하여 9000바이트의 점보 프레임을 사용하도록 인터페이스 1/12를 구성합니다.

    interface ethernet 1/12
      mtu 9216
      exit

7.3.10. LLDP 검색 정보

ironic-python-agent 서비스는 연결된 스위치에서 LLDP 패킷을 수신 대기합니다. 수집된 정보에는 스위치 이름, 포트 세부 정보 및 사용 가능한 VLAN이 포함될 수 있습니다. Cisco Discovery Protocol(CDP)과 유사하게 LLDP는 director 인트로스펙션 프로세스 중에 물리적 하드웨어 검색을 지원합니다.

7.3.11. Cisco Nexus 7000 스위치에 대한 LLDP 구성

절차

  • Cisco Nexus 7000 시리즈 스위치에서 개별 인터페이스에 LLDP를 활성화할 수 있습니다.

    interface ethernet 1/12
      lldp transmit
      lldp receive
      no lacp suspend-individual
      no lacp graceful-convergence
    
    interface ethernet 1/13
      lldp transmit
      lldp receive
      no lacp suspend-individual
      no lacp graceful-convergence
참고

running-config를 startup-config: copy running-config startup-config 에 복사하여 변경 사항을 저장하십시오.

7.4. Cumulus Linux 스위치 구성

7.4.1. 트렁크 포트 정보

OpenStack Networking을 사용하면 물리 네트워크에 이미 존재하는 VLAN에 인스턴스를 연결할 수 있습니다. 트렁크 라는 용어는 여러 VLAN이 동일한 포트를 통과할 수 있는 포트를 설명하는 데 사용됩니다. 이러한 포트를 사용하여 VLAN은 가상 스위치를 포함하여 여러 스위치에 걸쳐 있을 수 있습니다. 예를 들어 물리적 네트워크에서 VLAN110으로 태그된 트래픽이 Compute 노드에 도달하고 8021q 모듈은 태그된 트래픽을 vSwitch의 적절한 VLAN으로 보냅니다.

7.4.2. Cumulus Linux 스위치에 대한 트렁크 포트 구성

이 구성에서는 물리적 노드에 물리적 스위치의 포트 swp1 및 swp2에 연결된 것으로 가정합니다.

중요

이러한 값은 다음과 같습니다. 이 예제의 값은 해당 환경과 일치하도록 변경해야 합니다. 조정 없이 이러한 값을 스위치 구성에 복사하고 붙여넣으면 예기치 않은 중단이 발생할 수 있습니다.

절차

  • 다음 구성 구문을 사용하여 VLAN 100 및 200의 트래픽이 인스턴스로 전달될 수 있도록 허용합니다.

    auto bridge
    iface bridge
      bridge-vlan-aware yes
      bridge-ports glob swp1-2
      bridge-vids 100 200

7.4.3. 액세스 포트 정보

컴퓨팅 노드의 모든 NIC가 인스턴스 트래픽을 전달하는 것은 아니므로 여러 VLAN이 통과할 수 있도록 모든 NIC를 구성할 필요가 없습니다. 액세스 포트에는 VLAN이 하나만 필요하며, 관리 트래픽 또는 블록 스토리지 데이터와 같은 기타 운영 요구 사항을 충족할 수 있습니다. 이러한 포트는 일반적으로 액세스 포트라고 하며 일반적으로 트렁크 포트보다 간단한 구성이 필요합니다.

7.4.4. Cumulus Linux 스위치에 대한 액세스 포트 구성

이 설정에서는 물리적 노드에 물리적 스위치의 인터페이스에 이더넷이 연결되어 있다고 가정합니다. Cumulus Linux 스위치는 관리 인터페이스에 eth 를 사용하고 액세스/트리크 포트에는 swp 를 사용합니다.

중요

이러한 값은 다음과 같습니다. 이 예제의 값은 해당 환경과 일치하도록 변경해야 합니다. 조정 없이 이러한 값을 스위치 구성에 복사하고 붙여넣으면 예기치 않은 중단이 발생할 수 있습니다.

절차

  • 그림 7.1. “네트워크 레이아웃 샘플” 다이어그램의 예제를 사용하여 swp1 (Cumulus Linux 스위치)은 액세스 포트로 구성됩니다.

    auto bridge
    iface bridge
      bridge-vlan-aware yes
      bridge-ports glob swp1-2
      bridge-vids 100 200
    
    
    auto swp1
    iface swp1
      bridge-access 100
    
    
    auto swp2
    iface swp2
      bridge-access 200

7.4.5. LACP 포트 집계 정보

LACP(Link Aggregation Control Protocol)를 사용하여 여러 개의 물리적 NIC를 함께 번들하여 단일 논리 채널을 구성할 수 있습니다. 802.3ad (또는 Linux에서 본딩 모드 4)라고도 하는 LACP는 로드 밸런싱 및 내결함성을 위한 동적 본딩을 생성합니다. 물리적인 NIC와 물리적 스위치 포트 모두에서 LACP를 구성해야 합니다.

추가 리소스

7.4.6. MTU 설정 정보

특정 유형의 네트워크 트래픽에 대해 MTU 크기를 조정해야 합니다. 예를 들어, 특정 NFS 또는 iSCSI 트래픽에는 점보 프레임(9000바이트)이 필요합니다.

참고

가상 스위치를 포함하여 트래픽이 통과할 것으로 예상되는 모든 홉의 MTU 설정을 엔드 투 엔드에서 변경해야 합니다.

7.4.7. Cumulus Linux 스위치의 MTU 설정 구성

절차

  • 이 예제에서는 Cumulus Linux 스위치에서 점보 프레임을 활성화합니다.

    auto swp1
    iface swp1
      mtu 9000
    참고

    업데이트된 구성을 다시 로드하여 변경 사항을 적용하십시오. sudo ifreload -a

7.4.8. LLDP 검색 정보

ironic-python-agent 서비스는 연결된 스위치에서 LLDP 패킷을 수신 대기합니다. 수집된 정보에는 스위치 이름, 포트 세부 정보 및 사용 가능한 VLAN이 포함될 수 있습니다. Cisco Discovery Protocol(CDP)과 유사하게 LLDP는 director 인트로스펙션 프로세스 중에 물리적 하드웨어 검색을 지원합니다.

7.4.9. Cumulus Linux 스위치에 대한 LLDP 구성

기본적으로 LLDP 서비스 lldpd는 데몬으로 실행되며 스위치가 부팅될 때 시작됩니다.

절차

  • 모든 포트/인터페이스에서 LLDP 주변을 모두 보려면 다음 명령을 실행합니다.

    cumulus@switch$ netshow lldp
    Local Port  Speed  Mode         Remote Port   Remote Host Summary
    ----------  ---    ---------    -----  -----  ----------- --------
    eth0        10G    Mgmt         ====   swp6   mgmt-sw     IP: 10.0.1.11/24
    swp51       10G    Interface/L3 ====   swp1   spine01     IP: 10.0.0.11/32
    swp52       10G    Interface/L  ====   swp1   spine02     IP: 10.0.0.11/32

7.5. Extreme Exos 스위치 구성

7.5.1. 트렁크 포트 정보

OpenStack Networking을 사용하면 물리 네트워크에 이미 존재하는 VLAN에 인스턴스를 연결할 수 있습니다. 트렁크 라는 용어는 여러 VLAN이 동일한 포트를 통과할 수 있는 포트를 설명하는 데 사용됩니다. 이러한 포트를 사용하여 VLAN은 가상 스위치를 포함하여 여러 스위치에 걸쳐 있을 수 있습니다. 예를 들어 물리적 네트워크에서 VLAN110으로 태그된 트래픽이 Compute 노드에 도달하고 8021q 모듈은 태그된 트래픽을 vSwitch의 적절한 VLAN으로 보냅니다.

7.5.2. Extreme Networks EXOS 스위치에서 트렁크 포트 구성

X-670 시리즈 스위치를 사용하는 경우 다음 예제를 참조하여 VLAN 110과 111의 트래픽이 인스턴스로 통과할 수 있도록 허용합니다.

중요

이러한 값은 다음과 같습니다. 이 예제의 값은 해당 환경과 일치하도록 변경해야 합니다. 조정 없이 이러한 값을 스위치 구성에 복사하고 붙여넣으면 예기치 않은 중단이 발생할 수 있습니다.

절차

  • 이 설정에서는 물리적 노드에 물리적 스위치의 인터페이스 24에 이더넷 이더넷이 연결되어 있다고 가정합니다. 이 예에서 DATA 및 MNGT는 VLAN 이름입니다.

    #create vlan DATA tag 110
    #create vlan MNGT tag 111
    #configure vlan DATA add ports 24 tagged
    #configure vlan MNGT add ports 24 tagged

7.5.3. 액세스 포트 정보

컴퓨팅 노드의 모든 NIC가 인스턴스 트래픽을 전달하는 것은 아니므로 여러 VLAN이 통과할 수 있도록 모든 NIC를 구성할 필요가 없습니다. 액세스 포트에는 VLAN이 하나만 필요하며, 관리 트래픽 또는 블록 스토리지 데이터와 같은 기타 운영 요구 사항을 충족할 수 있습니다. 이러한 포트는 일반적으로 액세스 포트라고 하며 일반적으로 트렁크 포트보다 간단한 구성이 필요합니다.

7.5.4. Extreme Networks EXOS 스위치에 대한 액세스 포트 구성

이 설정에서는 물리적 노드에 물리적 스위치의 인터페이스 10 에 이더넷 케이블이 연결되어 있다고 가정합니다.

중요

이러한 값은 다음과 같습니다. 이 예제의 값은 해당 환경과 일치하도록 변경해야 합니다. 조정 없이 이러한 값을 스위치 구성에 복사하고 붙여넣으면 예기치 않은 중단이 발생할 수 있습니다.

절차

  • 이 구성 예에서 Extreme Networks X-670 시리즈 스위치에서 10eth1 의 액세스 포트로 사용됩니다.

    create vlan VLANNAME tag NUMBER
    configure vlan Default delete ports PORTSTRING
    configure vlan VLANNAME add ports PORTSTRING untagged

    예를 들면 다음과 같습니다.

    #create vlan DATA tag 110
    #configure vlan Default delete ports 10
    #configure vlan DATA add ports 10 untagged

7.5.5. LACP 포트 집계 정보

LACP(Link Aggregation Control Protocol)를 사용하여 여러 개의 물리적 NIC를 함께 번들하여 단일 논리 채널을 구성할 수 있습니다. 802.3ad (또는 Linux에서 본딩 모드 4)라고도 하는 LACP는 로드 밸런싱 및 내결함성을 위한 동적 본딩을 생성합니다. 물리적인 NIC와 물리적 스위치 포트 모두에서 LACP를 구성해야 합니다.

추가 리소스

7.5.6. 물리적 NIC에서 LACP 구성

물리적 NIC에서 LACP(Link Aggregation Control Protocol)를 구성할 수 있습니다.

절차

  1. /home/stack/network-environment.yaml 파일을 편집합니다.

    - type: linux_bond
      name: bond1
      mtu: 9000
      bonding_options:{get_param: BondInterfaceOvsOptions};
      members:
        - type: interface
          name: nic3
          mtu: 9000
          primary: true
        - type: interface
          name: nic4
          mtu: 9000
  2. LACP를 사용하도록 Open vSwitch 브리지를 구성합니다.

    BondInterfaceOvsOptions:
        "mode=802.3ad"

추가 리소스

7.5.7. Extreme Networks EXOS 스위치에서 LACP 구성

절차

  • 이 예에서 Compute 노드에는 VLAN 100을 사용하는 두 개의 NIC가 있습니다.

    enable sharing MASTERPORT grouping ALL_LAG_PORTS lacp
    configure vlan VLANNAME add ports PORTSTRING tagged

    예를 들면 다음과 같습니다.

    #enable sharing 11 grouping 11,12 lacp
    #configure vlan DATA add port 11 untagged
    참고

    LACP 협상 스크립트에서 시간제한 기간을 조정해야 할 수도 있습니다. 자세한 내용은 https://gtacknowledge.extremenetworks.com/articles/How_To/LACP-configured-ports-interfere-with-PXE-DHCP-on-servers을 참조하십시오.

7.5.8. MTU 설정 정보

특정 유형의 네트워크 트래픽에 대해 MTU 크기를 조정해야 합니다. 예를 들어, 특정 NFS 또는 iSCSI 트래픽에는 점보 프레임(9000바이트)이 필요합니다.

참고

가상 스위치를 포함하여 트래픽이 통과할 것으로 예상되는 모든 홉의 MTU 설정을 엔드 투 엔드에서 변경해야 합니다.

7.5.9. Extreme Networks EXOS 스위치에서 MTU 설정 구성

절차

  • 이 예제에서 명령을 실행하여 Extreme Networks EXOS 스위치에서 점보 프레임을 활성화하고 9000바이트로 IP 패킷 전달 지원을 구성합니다.

    enable jumbo-frame ports PORTSTRING
    configure ip-mtu 9000 vlan VLANNAME

    예제

    # enable jumbo-frame ports 11
    # configure ip-mtu 9000 vlan DATA

7.5.10. LLDP 검색 정보

ironic-python-agent 서비스는 연결된 스위치에서 LLDP 패킷을 수신 대기합니다. 수집된 정보에는 스위치 이름, 포트 세부 정보 및 사용 가능한 VLAN이 포함될 수 있습니다. Cisco Discovery Protocol(CDP)과 유사하게 LLDP는 director 인트로스펙션 프로세스 중에 물리적 하드웨어 검색을 지원합니다.

7.5.11. Extreme Networks EXOS 스위치에서 LLDP 설정 구성

절차

  • 이 예에서 LLDP는 Extreme Networks EXOS 스위치에서 활성화됩니다. 11 은 포트 문자열을 나타냅니다.
enable lldp ports 11

7.6. Juniper EX 시리즈 스위치 구성

7.6.1. 트렁크 포트 정보

OpenStack Networking을 사용하면 물리 네트워크에 이미 존재하는 VLAN에 인스턴스를 연결할 수 있습니다. 트렁크 라는 용어는 여러 VLAN이 동일한 포트를 통과할 수 있는 포트를 설명하는 데 사용됩니다. 이러한 포트를 사용하여 VLAN은 가상 스위치를 포함하여 여러 스위치에 걸쳐 있을 수 있습니다. 예를 들어 물리적 네트워크에서 VLAN110으로 태그된 트래픽이 Compute 노드에 도달하고 8021q 모듈은 태그된 트래픽을 vSwitch의 적절한 VLAN으로 보냅니다.

7.6.2. Juniper EX Series 스위치에 대한 트렁크 포트 구성

절차

  • Juniper JunOS를 실행하는 Juniper EX 시리즈 스위치를 사용하는 경우 다음 구성 구문을 사용하여 VLAN 110 및 111의 트래픽이 인스턴스로 통과할 수 있도록 허용합니다.

    이 설정에서는 물리적인 노드에 물리적 스위치의 인터페이스 ge-1/0/12에 연결된 이더넷이 있다고 가정합니다.

    중요

    이러한 값은 다음과 같습니다. 이 예제의 값은 해당 환경과 일치하도록 변경해야 합니다. 조정 없이 이러한 값을 스위치 구성에 복사하고 붙여넣으면 예기치 않은 중단이 발생할 수 있습니다.

     ge-1/0/12 {
              description Trunk to Compute Node;
                  unit 0 {
                      family ethernet-switching {
                          port-mode trunk;
                          vlan {
                              members [110 111];
                               }
                          native-vlan-id 2;
                      }
                  }
    }

7.6.3. 액세스 포트 정보

컴퓨팅 노드의 모든 NIC가 인스턴스 트래픽을 전달하는 것은 아니므로 여러 VLAN이 통과할 수 있도록 모든 NIC를 구성할 필요가 없습니다. 액세스 포트에는 VLAN이 하나만 필요하며, 관리 트래픽 또는 블록 스토리지 데이터와 같은 기타 운영 요구 사항을 충족할 수 있습니다. 이러한 포트는 일반적으로 액세스 포트라고 하며 일반적으로 트렁크 포트보다 간단한 구성이 필요합니다.

7.6.4. Juniper EX 시리즈 스위치에 대한 액세스 포트 구성

의 이 예에서는 Juniper EX 시리즈 스위치는 ge-1/0/13eth1 의 액세스 포트로 표시합니다.

+

중요

이러한 값은 다음과 같습니다. 이 예제의 값은 해당 환경과 일치하도록 변경해야 합니다. 조정 없이 이러한 값을 스위치 구성에 복사하고 붙여넣으면 예기치 않은 중단이 발생할 수 있습니다.

절차

이 설정에서는 물리적 노드에 물리적 스위치의 인터페이스 ge-1/0/13 에 연결된 이더넷 케이블이 있다고 가정합니다.

+

 ge-1/0/13 {
          description Access port for Compute Node
              unit 0 {
                  family ethernet-switching {
                      port-mode access;
                      vlan {
                          members 200;
                           }
                      native-vlan-id 2;
                  }
              }
}

7.6.5. LACP 포트 집계 정보

LACP(Link Aggregation Control Protocol)를 사용하여 여러 개의 물리적 NIC를 함께 번들하여 단일 논리 채널을 구성할 수 있습니다. 802.3ad (또는 Linux에서 본딩 모드 4)라고도 하는 LACP는 로드 밸런싱 및 내결함성을 위한 동적 본딩을 생성합니다. 물리적인 NIC와 물리적 스위치 포트 모두에서 LACP를 구성해야 합니다.

추가 리소스

7.6.6. 물리적 NIC에서 LACP 구성

물리적 NIC에서 LACP(Link Aggregation Control Protocol)를 구성할 수 있습니다.

절차

  1. /home/stack/network-environment.yaml 파일을 편집합니다.

    - type: linux_bond
      name: bond1
      mtu: 9000
      bonding_options:{get_param: BondInterfaceOvsOptions};
      members:
        - type: interface
          name: nic3
          mtu: 9000
          primary: true
        - type: interface
          name: nic4
          mtu: 9000
  2. LACP를 사용하도록 Open vSwitch 브리지를 구성합니다.

    BondInterfaceOvsOptions:
        "mode=802.3ad"

추가 리소스

7.6.7. Juniper EX 시리즈 스위치에 대한 LACP 구성

이 예에서 Compute 노드에는 VLAN 100을 사용하는 두 개의 NIC가 있습니다.

절차

  1. 컴퓨팅 노드의 NIC 두 개를 스위치(예: 포트 12 및 13)에 물리적으로 연결합니다.
  2. 포트 집계를 생성합니다.

    chassis {
        aggregated-devices {
            ethernet {
                device-count 1;
            }
        }
    }
  3. 포트 집계에 참여하도록 스위치 포트 12(ge-1/0/12) 및 13(ge-1/0/13) 구성합니다.

    interfaces {
        ge-1/0/12 {
            gigether-options {
                802.3ad ae1;
            }
        }
        ge-1/0/13 {
            gigether-options {
                802.3ad ae1;
                }
            }
    }
    참고

    Red Hat OpenStack Platform director 배포의 경우 본딩에서 PXE 부팅을 위해서는 인트로스펙션 및 최초 부팅 중에 하나의 본딩 멤버만 표시되는 lacp force-up toensure로 본딩 멤버 중 하나를 구성해야 합니다. lacp force-up으로 구성하는 본딩 멤버는 instackenv.json 에 MAC 주소가 있는 본딩 멤버와 동일해야 합니다( ironic에 알려진 MAC 주소는 force-up으로 구성된 동일한 MAC 주소여야 합니다).

  4. 포트 집계 ae1 에서 LACP를 활성화합니다.

    interfaces {
        ae1 {
            aggregated-ether-options {
                lacp {
                    active;
                }
            }
        }
    }
  5. VLAN 100에 집계 ae1 을 추가합니다.

    interfaces {
        ae1 {
            vlan-tagging;
            native-vlan-id 2;
            unit 100 {
                vlan-id 100;
            }
        }
    }
  6. 새 포트 채널을 검토합니다. 결과 출력에는 멤버 포트 ge-1/0/12ge-1/0/13 이 있는 새 포트 집계 ae1 이 나열됩니다.

    > show lacp statistics interfaces ae1
    
    Aggregated interface: ae1
    LACP Statistics: LACP Rx LACP Tx Unknown Rx Illegal Rx
    ge-1/0/12 0 0 0 0
    ge-1/0/13 0 0 0 0
    참고

    commit 명령을 실행하여 변경 사항을 적용해야 합니다.

7.6.8. MTU 설정 정보

특정 유형의 네트워크 트래픽에 대해 MTU 크기를 조정해야 합니다. 예를 들어, 특정 NFS 또는 iSCSI 트래픽에는 점보 프레임(9000바이트)이 필요합니다.

참고

가상 스위치를 포함하여 트래픽이 통과할 것으로 예상되는 모든 홉의 MTU 설정을 엔드 투 엔드에서 변경해야 합니다.

7.6.9. Juniper EX 시리즈 스위치의 MTU 설정 구성

이 예제에서는 Juniper EX4200 스위치의 점보 프레임을 활성화합니다.

참고

MTU 값은 Juniper 또는 Cisco 장치를 사용 중인지에 따라 다르게 계산됩니다. 예를 들어, Juniper의 9216 은 Cisco의 9202 와 동일합니다. 추가 바이트는 L2 헤더에 사용됩니다. 여기서 Cisco는 지정된 MTU 값에 자동으로 추가되지만 사용 가능한 MTU는 Juniper를 사용할 때 지정된 것보다 14바이트 작을 것입니다. 따라서 VLAN에서 9000 의 MTU를 지원하려면 Juniper에 9014 의 MTU를 구성해야 합니다.

절차

  1. Juniper EX 시리즈 스위치의 경우 MTU 설정은 개별 인터페이스에 대해 설정됩니다. 이 명령은 ge-1/0/14ge-1/0/15 포트에서 점보 프레임을 구성합니다.

    set interfaces ge-1/0/14 mtu 9216
    set interfaces ge-1/0/15 mtu 9216
    참고

    commit 명령을 실행하여 변경 사항을 저장해야 합니다.

  2. LACP 집계를 사용하는 경우 멤버 NIC에 없는 MTU 크기를 설정해야 합니다. 예를 들어 이 설정은 ae1 집계의 MTU 크기를 구성합니다.

     set interfaces ae1 mtu 9216

7.6.10. LLDP 검색 정보

ironic-python-agent 서비스는 연결된 스위치에서 LLDP 패킷을 수신 대기합니다. 수집된 정보에는 스위치 이름, 포트 세부 정보 및 사용 가능한 VLAN이 포함될 수 있습니다. Cisco Discovery Protocol(CDP)과 유사하게 LLDP는 director 인트로스펙션 프로세스 중에 물리적 하드웨어 검색을 지원합니다.

7.6.11. Juniper EX 시리즈 스위치에 대한 LLDP 구성

전역적으로 모든 인터페이스 또는 개별 인터페이스에 대해 LLDP를 활성화할 수 있습니다.

절차

  • 다음도 Juniper EX 4200 스위치에서 LLDP를 전역적으로 사용하도록 설정합니다.

    lldp {
    	interface all{
    		enable;
    	}
    	}
    }
  • 다음을 사용하여 단일 인터페이스 ge-1/0/14 에 LLDP를 활성화합니다.

    lldp {
    	interface ge-1/0/14{
    		enable;
    	}
    	}
    }
    참고

    commit 명령을 실행하여 변경 사항을 적용해야 합니다.

8장. 최대 전송 단위(MTU) 설정 구성

8.1. MTU 개요

OpenStack Networking은 인스턴스에 안전하게 적용할 수 있는 최대 전송 단위(MTU) 크기를 계산할 수 있습니다. MTU 값은 단일 네트워크 패킷이 전송할 수 있는 최대 데이터 양을 지정합니다. 이 수는 애플리케이션에 가장 적합한 크기에 따라 변수입니다. 예를 들어 NFS 공유에서는 etcdctl 애플리케이션의 해당 MTU 크기를 다른 MTU 크기를 필요로 할 수 있습니다.

참고

openstack network show <network_name> 명령을 사용하여 OpenStack Networking에서 계산하는 가장 큰 MTU 값을 볼 수 있습니다. net-mtu 는 일부 구현에 없는 neutron API 확장입니다. 필요한 MTU 값은 인스턴스에서 지원하는 경우 DHCPv4 클라이언트에 및 라우터 알림(RA) 패킷을 통해 IPv6 클라이언트에 알릴 수 있습니다. 라우터 알림을 보내려면 네트워크를 라우터에 연결해야 합니다.

MTU 설정을 엔드 투 엔드에서 일관되게 구성해야 합니다. 즉, VM, 가상 네트워크 인프라, 물리적 네트워크 및 대상 서버를 포함하여 패킷이 통과하는 모든 지점에서 MTU 설정이 동일해야 합니다.

예를 들어 다음 다이어그램의 원은 인스턴스와 물리적 서버 간의 트래픽에 대해 MTU 값을 조정해야 하는 다양한 지점을 나타냅니다. 특정 MTU 크기의 패킷을 수용하기 위해 네트워크 트래픽을 처리하는 매우 인터페이스의 MTU 값을 변경해야 합니다. 이는 192.168.200.15 인스턴스에서 물리적 서버 10.20.15.25 로 트래픽이 이동하는 경우 필요합니다.

MTU 설정

일치하지 않는 MTU 값으로 인해 여러 네트워크 문제가 발생할 수 있으며, 가장 일반적인 것은 임의 패킷 손실로 인해 연결이 떨어지고 네트워크 성능이 저하됩니다. 이러한 문제는 올바른 MTU 값이 있는지 확인하기 위해 가능한 모든 네트워크 포인트를 식별하고 검사해야 하므로 문제 해결에 문제가 있습니다.

8.2. Director에서 MTU 설정 구성

이 예제에서는 NIC 구성 템플릿을 사용하여 MTU를 설정하는 방법을 보여줍니다. 브리지, 본딩(해당하는 경우), 인터페이스 및 VLAN에서 MTU를 설정해야 합니다.

            -
              type: ovs_bridge
              name: br-isolated
              use_dhcp: false
              mtu: 9000    # <--- Set MTU
              members:
                -
                  type: ovs_bond
                  name: bond1
                  mtu: 9000    # <--- Set MTU
                  ovs_options: {get_param: BondInterfaceOvsOptions}
                  members:
                    -
                      type: interface
                      name: ens15f0
                      mtu: 9000    # <--- Set MTU
                      primary: true
                    -
                      type: interface
                      name: enp131s0f0
                      mtu: 9000    # <--- Set MTU
                -
                  type: vlan
                  device: bond1
                  vlan_id: {get_param: InternalApiNetworkVlanID}
                  mtu: 9000    # <--- Set MTU
                  addresses:
                  -
                    ip_netmask: {get_param: InternalApiIpSubnet}
                -
                  type: vlan
                  device: bond1
                  mtu: 9000    # <--- Set MTU
                  vlan_id: {get_param: TenantNetworkVlanID}
                  addresses:
                  -
                    ip_netmask: {get_param: TenantIpSubnet}

8.3. 생성된 MTU 계산 검토

계산된 MTU 값은 인스턴스에서 사용할 수 있는 가장 큰 MTU 값입니다. 이 계산된 MTU 값을 사용하여 네트워크 트래픽의 경로와 관련된 모든 인터페이스를 구성합니다.

# openstack network show <network>

9장. QoS(Quality of Service) 정책을 사용하여 데이터 트래픽 관리

RHOSP(Red Hat OpenStack Platform) 네트워크의 송신 및 수신 트래픽에 속도 제한을 적용하려면 QoS(Quality of Service) 정책을 사용하여 VM 인스턴스에 다양한 서비스 수준을 제공할 수 있습니다.

QoS 정책을 개별 포트에 적용하거나 QoS 정책을 특정 정책이 연결된 포트가 정책을 상속하지 않는 프로젝트 네트워크에 적용할 수 있습니다.

참고

DHCP 및 내부 라우터 포트와 같은 내부 네트워크 소유 포트는 네트워크 정책 애플리케이션에서 제외됩니다.

QoS 정책을 동적으로 적용, 수정 또는 제거할 수 있습니다. 그러나 최소 대역폭 QoS 정책의 경우 정책이 할당된 포트를 사용하는 인스턴스가 없는 경우에만 수정 사항을 적용할 수 있습니다.

9.1. QoS 규칙

RHOSP(Red Hat OpenStack Platform) 네트워킹 서비스(neutron)에서 QoS(Quality of Service) 정책을 정의하도록 다음 규칙 유형을 구성할 수 있습니다.

최소 대역폭 (minimum_bandwidth)
특정 유형의 트래픽에 대한 최소 대역폭 제약 조건을 제공합니다. 구현된 경우 규칙이 적용되는 각 포트에 대해 지정된 대역폭보다 적게 제공하지 않도록 최선의 노력을 기울이고 있습니다.
대역폭 제한 (bandwidth_limit)
네트워크, 포트, 유동 IP 및 라우터 게이트웨이 IP에 대한 대역폭 제한을 제공합니다. 구현된 경우 지정된 비율을 초과하는 모든 트래픽이 삭제됩니다.
ECDHEP 마크 (dscp_marking)
네트워크 트래픽을 다른 서비스 코드 포인트(DSCP) 값으로 표시합니다.

QoS 정책은 가상 머신 인스턴스 배치, 유동 IP 할당, 게이트웨이 IP 할당 등 다양한 컨텍스트에서 적용할 수 있습니다.

사용하는 메커니즘 드라이버 및 메커니즘 드라이버에 따라 QoS 규칙은 송신 트래픽(인스턴스에서 업로드), 수신 트래픽(인스턴스로 다운로드) 또는 둘 다에 영향을 미칩니다.

표 9.1. 드라이버에서 지원되는 트래픽 방향(모든 QoS 규칙 유형)

Rule

메커니즘 드라이버에서 지원되는 트래픽 방향

ML2/OVS

ML2/SR-IOV

ML2/OVN

최소 대역폭

송신 전용 [4]ECDHE

송신 전용

현재 지원 안 함 [6]

대역폭 제한

송신 [1] [2] 및 수신

송신 만 [3]

송신 및 수신

DSCP 표시

송신 전용

해당 없음

송신만 [7]

[1] OVS 송신 대역폭 제한은 DestinationRule 인터페이스에서 수행되며 트래픽 컬링이 아니라 트래픽 형성입니다.

[2] RHOSP 16.2.2 이상에서는 ip link 명령을 사용하여 네트워크 인터페이스에 QoS 정책을 적용하여 하드웨어 오프로드된 포트에서 OVS 송신 대역폭 제한이 지원됩니다.

[3] 메커니즘 드라이버는 이를 지원하지 않기 때문에 max-burst-kbits 매개변수를 무시합니다.

[4] 규칙은 튜닝되지 않은 네트워크( flat 및 VLAN)에만 적용됩니다.

[5] ip link 명령을 사용하여 네트워크 인터페이스에 QoS 정책을 적용하여 하드웨어 오프로드된 포트에서 OVS 송신 최소 대역폭이 지원됩니다.

[6] https://bugzilla.redhat.com/show_bug.cgi?id=2060310

[7] ML2/OVN은 터널링된 프로토콜에서ECDHEP 표시를 지원하지 않습니다.

표 9.2. 보고 및 스케줄링을 위해 드라이버에서 지원되는 트래픽 방향(최소 대역폭만 해당)

시행 유형

방향 메커니즘 드라이버에서 지원되는 트래픽

ML2/OVS

ML2/SR-IOV

ML2/OVN

배치

송신 및 수신

송신 및 수신

현재 지원 없음

표 9.3. 시행 유형에서 드라이버에 의해 지원되는 트래픽 방향 (대역폭 제한만 해당)

시행 유형

메커니즘 드라이버에서 지원되는 트래픽 방향

ML2/OVS

ML2/OVN

부동 IP

송신 및 수신

송신 및 수신

게이트웨이 IP

송신 및 수신

현재 지원 안 함 [1]

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2064185

9.2. QoS 정책에 대한 네트워킹 서비스 구성

RHOSP(Red Hat OpenStack Platform) 네트워킹 서비스(neutron)의 서비스 품질은 qos 서비스 플러그인을 통해 제공됩니다. ML2/OVS 및 ML2/OVN 메커니즘 드라이버를 사용하면 qos 가 기본적으로 로드됩니다. 그러나 ML2/SR-IOV에는 적용되지 않습니다.

ML2/OVS 및 ML2/SR-IOV 메커니즘 드라이버와 함께 qos 서비스 플러그인을 사용하는 경우 해당 에이전트에 qos 확장도 로드해야 합니다.

다음 목록에는 QoS에 대한 네트워킹 서비스를 구성하기 위해 수행해야 하는 작업이 요약되어 있습니다. 작업 세부 정보는 다음 목록을 따릅니다.

  • 모든 유형의 QoS 정책의 경우:

    • qos 서비스 플러그인을 추가합니다.
    • 에이전트의 qos 확장을 추가합니다(OVS 및 SR-IOV만 해당).
  • 최소 대역폭 정책만 사용하여 VM 인스턴스를 예약하기 위한 추가 작업:

    • Compute 서비스(nova)에서 사용하는 이름과 다른 하이퍼바이저 이름을 지정합니다.
    • 각 컴퓨팅 노드에서 관련 에이전트에 대한 리소스 공급자 수신 및 송신 대역폭을 구성합니다.
    • (선택 사항) vnic_types 를 지원하지 않는 것으로 표시합니다.
  • 터널링과 함께 ML/OVS를 사용하는 시스템에서 DestinationRuleP 표시 정책에 대한 추가 작업:

    • dscp_inherittrue 로 설정합니다.

사전 요구 사항

  • RHOSP 언더클라우드에 액세스할 수 있는 stack 사용자여야 합니다.

절차

  1. 언더클라우드 호스트에 stack 사용자로 로그인합니다.
  2. 언더클라우드 인증 정보 파일을 소싱합니다.

    $ source ~/stackrc
  3. qos 서비스 플러그인이 아직 로드되지 않았는지 확인합니다.

    $ openstack network qos policy list

    qos 서비스 플러그인이 로드되지 않은 경우 ResourceNotFound 오류가 발생합니다. 오류가 발생하지 않으면 플러그인이 로드되므로 이 항목의 단계를 수행할 필요가 없습니다.

  4. YAML 사용자 지정 환경 파일을 생성합니다.

    예제

    $ vi /home/stack/templates/my-neutron-environment.yaml

  5. 환경 파일에는 parameter_defaults 키워드가 포함되어야 합니다. parameter_defaults 아래의 새 행에서 NeutronServicePlugins 매개변수에 qos 를 추가합니다.

    parameter_defaults:
       NeutronServicePlugins: "qos"
  6. ML2/OVS 및 ML2/SR-IOV 메커니즘 드라이버를 사용하는 경우 NeutronAgentExtensions 또는 NeutronSriovAgentExtensions 변수를 각각 사용하여 에이전트에 qos 확장을 로드해야 합니다.

    • ML2/OVS

      parameter_defaults:
        NeutronServicePlugins: "qos"
        NeutronAgentExtensions: "qos"
    • ML2/SR-IOV

      parameter_defaults:
        NeutronServicePlugins: "qos"
        NeutronSriovAgentExtensions: "qos"
  7. 최소 대역폭 QoS 정책을 사용하여 VM 인스턴스를 예약하려면 다음을 수행해야 합니다.

    1. 플러그인 목록에 배치를 추가하고 목록에 qos:도 포함되어 있는지 확인하십시오.

      parameter_defaults:
         NeutronServicePlugins: "qos,placement"
    2. 하이퍼바이저 이름이 Compute 서비스(nova)에서 사용하는 표준 하이퍼바이저 이름과 일치하는 경우 7.iii 단계로 건너뜁니다.

      하이퍼바이저 이름이 Compute 서비스에서 사용하는 표준 하이퍼바이저 이름과 일치하지 않는 경우 resource_provider_default_hypervisor 를 사용하여 대체 하이퍼바이저 이름을 지정합니다.

      • ML2/OVS

        parameter_defaults:
          NeutronServicePlugins: "qos,placement"
          ExtraConfig:
            Neutron::agents::ml2::ovs::resource_provider_default_hypervisor: %{hiera('fqdn_canonical')}
      • ML2/SR-IOV

        parameter_defaults:
          NeutronServicePlugins: "qos,placement"
          ExtraConfig:
            Neutron::agents::ml2::sriov::resource_provider_default_hypervisor: %{hiera('fqdn_canonical')}
        중요

        대체 하이퍼바이저 이름을 설정하는 또 다른 방법은 resource_provider_hypervisor 를 사용하는 것입니다.

        • ML2/OVS

          parameter_defaults:
            ExtraConfig:
               Neutron::agents::ml2::ovs::resource_provider_hypervisors:"ens5:%{hiera('fqdn_canonical')},ens6:%{hiera('fqdn_canonical')}"
        • ML2/SR-IOV

          parameter_defaults:
            ExtraConfig:
               Neutron::agents::ml2::sriov::resource_provider_hypervisors:
               "ens5:%{hiera('fqdn_canonical')},ens6:%{hiera('fqdn_canonical')}"
    3. 최소 대역폭을 제공해야 하는 각 컴퓨팅 노드에서 관련 에이전트의 리소스 공급자 수신 및 송신 대역폭을 구성합니다.

      다음 형식을 사용하여 송신, 수신 또는 둘 다를 구성할 수 있습니다.

      • kbps에서 송신 대역폭만 구성합니다.

        NeutronOvsResourceProviderBandwidths: <bridge0>:<egress_kbps>:,<bridge1>:<egress_kbps>:,...,<bridgeN>:<egress_kbps>:
      • kbps에서 수신 대역폭만 구성합니다.

        NeutronOvsResourceProviderBandwidths: <bridge0>::<ingress_kbps>,<bridge1>::<ingress_kbps>,...,<bridgeN>::<ingress_kbps>
      • kbps에서 송신 및 수신 대역폭을 모두 구성합니다.

        NeutronOvsResourceProviderBandwidths: <bridge0>:<egress_kbps>:<ingress_kbps>,<bridge1>:<egress_kbps>:<ingress_kbps>,...,<bridgeN>:<egress_kbps>:<ingress_kbps>

        예 - OVS 에이전트

        OVS 에이전트에 대한 리소스 공급자 수신 및 송신 대역폭을 구성하려면 네트워크 환경 파일에 다음 구성을 추가합니다.

        parameter_defaults:
          ...
          NeutronBridgeMappings: physnet0:br-physnet0
          NeutronOvsResourceProviderBandwidths: br-physnet0:10000000:10000000

        예 - SRIOV 에이전트

        SRIOV 에이전트의 리소스 공급자 수신 및 송신 대역폭을 구성하려면 네트워크 환경 파일에 다음 구성을 추가합니다.

        parameter_defaults:
          ...
          NeutronML2PhysicalNetworkMtus: physnet0:1500,physnet1:1500
          NeutronSriovResourceProviderBandwidths: ens5:40000000:40000000,ens6:40000000:40000000
    4. 선택 사항: 여러 ML2 메커니즘 드라이버가 이를 기본적으로 지원하고 여러 에이전트가 배치 서비스에서 추적되는 경우 vnic_types 가 지원되지 않는 것으로 표시하려면 환경 파일에 다음 구성을 추가합니다.

      예 - OVS 에이전트

      parameter_defaults:
        ...
        NeutronOvsVnicTypeBlacklist: direct

      예 - SRIOV 에이전트

      parameter_defaults:
        ...
        NeutronSriovVnicTypeBlacklist: direct

  8. DestinationRuleP 표시 정책을 만들고 터널링 프로토콜(VXLAN 또는 GRE)과 함께 ML2/OVS을 사용하려면 NeutronAgentExtensions 에서 다음 행을 추가합니다.

    parameter_defaults:
      ...
      ControllerExtraConfig:
        neutron::config::server_config:
            agent/dscp_inherit:
                value: true

    dscp_inherittrue 인 경우 Networking 서비스는 내부 헤더의ECDHEP 값을 외부 헤더에 복사합니다.

  9. 배포 명령을 실행하고 코어 heat 템플릿, 기타 환경 파일 및 이 새로운 사용자 지정 환경 파일을 포함합니다.

    중요

    후속 환경 파일에 정의된 매개 변수와 리소스가 우선하므로 환경 파일의 순서가 중요합니다.

    예제

    $ openstack overcloud deploy --templates \
    -e <other_environment_files> \
    -e /home/stack/templates/my-neutron-environment.yaml

검증

  • qos 서비스 플러그인이 로드되었는지 확인합니다.

    $ openstack network qos policy list

    qos 서비스 플러그인이 로드되면 ResourceNotFound 오류가 수신되지 않습니다.

9.3. QoS 정책을 사용하여 최소 대역폭 제어

RHOSP(Red Hat OpenStack Platform) 네트워킹 서비스(neutron)의 경우 보장된 최소 대역폭 QoS 규칙을 다음 두 가지 컨텍스트에서 적용할 수 있습니다. 네트워킹 서비스 백엔드 시행 및 리소스 할당 스케줄링 시행.

네트워크 백엔드, ML2/OVS 또는 ML2/SR-IOV는 규칙이 적용되는 각 포트에 지정된 네트워크 대역폭보다 적은 수 없음을 보장합니다.

리소스 할당 스케줄링 대역폭 적용을 사용하는 경우 Compute 서비스(nova)는 최소 대역폭을 지원하는 호스트에 VM 인스턴스만 배치합니다.

네트워킹 서비스 백엔드 적용, 리소스 할당 스케줄링 적용 또는 둘 다를 사용하여 QoS minumum 대역폭 규칙을 적용할 수 있습니다.

다음 표에서는 최소 대역폭 QoS 정책을 지원하는 모듈식 계층 2(ML2) 메커니즘 드라이버를 식별합니다.

표 9.4. 최소 대역폭 QoS를 지원하는 ML2 메커니즘 드라이버

ML2 메커니즘 드라이버에이전트VNIC 유형

ML2/SR-IOV

sriovnicswitch

직접

ML2/OVS

openvswitch

Normal

9.3.1. 네트워킹 서비스 백엔드 시행을 사용하여 최소 대역폭 적용

RHOSP(Red Hat OpenStack Platform) QoS(Quality of Service) 정책을 포트에 적용하여 포트의 네트워크 트래픽에 대한 최소 대역폭을 보장할 수 있습니다. 이러한 포트는 플랫 또는 VLAN 물리적 네트워크에서 지원해야 합니다.

참고

현재 ML2/OVN(Open Virtual Network 메커니즘 드라이버)을 사용하는 Modular Layer 2 플러그인은 최소 대역폭 QoS 규칙을 지원하지 않습니다.

사전 요구 사항

  • RHOSP Networking 서비스(neutron)에 qos 서비스 플러그인이 로드되어야 합니다. (기본값입니다.)
  • 동일한 물리적 인터페이스에서 대역폭 보장을 사용하거나 사용하지 않는 포트를 혼합하지 마십시오. 이는 보장 없이 필요한 리소스(성당 거부)를 포트에 노출시킬 수 있기 때문입니다.

    작은 정보

    대역폭 보장 없이 해당 포트와 대역폭 보장을 사용하여 포트를 분리하기 위해 호스트 집계를 생성합니다.

절차

  1. 자격 증명 파일을 가져옵니다.

    예제

    $ source ~/overcloudrc

  2. Networking 서비스에 qos 서비스 플러그인이 로드되었는지 확인합니다.

    $ openstack network qos policy list

    qos 서비스 플러그인이 로드되지 않은 경우 ResourceNotFound 오류가 발생하고 계속하기 전에 qos 서비스 플러그인을 로드해야 합니다. 자세한 내용은 9.2절. “QoS 정책에 대한 네트워킹 서비스 구성”의 내용을 참조하십시오.

  3. QoS 정책을 생성할 프로젝트의 ID를 확인합니다.

    $ openstack project list

    샘플 출력

    +----------------------------------+----------+
    | ID                               | Name     |
    +----------------------------------+----------+
    | 4b0b98f8c6c040f38ba4f7146e8680f5 | auditors |
    | 519e6344f82e4c079c8e2eabb690023b | services |
    | 80bf5732752a41128e612fe615c886c6 | demo     |
    | 98a2f53c20ce4d50a40dac4a38016c69 | admin    |
    +----------------------------------+----------+

  4. 이전 단계의 프로젝트 ID를 사용하여 프로젝트에 대한 QoS 정책을 생성합니다.

    예제

    이 예에서는 admin 프로젝트에 대해 guaranteed_min_bw 라는 QoS 정책이 생성됩니다.

    $ openstack network qos policy create --share \
     --project 98a2f53c20ce4d50a40dac4a38016c69 guaranteed_min_bw
  5. 정책에 대한 규칙을 구성합니다.

    예제

    이 예에서는 guaranteed_min_bw 라는 정책에 대해 최소 대역폭이 40000000 kbps인 수신 및 송신에 대한 QoS 규칙이 생성됩니다.

    $ openstack network qos rule create \
     --type minimum-bandwidth --min-kbps 40000000 \
     --ingress guaranteed_min_bw
    
    $ openstack network qos rule create \
     --type minimum-bandwidth --min-kbps 40000000 \
     --egress guaranteed_min_bw
  6. 정책을 적용하도록 포트를 구성합니다.

    예제

    이 예에서 guaranteed_min_bw 정책은 포트 ID,ECDHE x9aiw1-2v74-144x-c2q8-ed8w423a6s12 에 적용됩니다.

    $ openstack port set --qos-policy guaranteed_min_bw \
     56x9aiw1-2v74-144x-c2q8-ed8w423a6s12

검증

  • ML2/SR-IOV

    루트 액세스를 사용하여 컴퓨팅 노드에 로그인하고 물리적 기능에 보관되는 가상 기능의 세부 정보를 표시합니다.

    예제

    # ip -details link show enp4s0f1

    샘플 출력

    50: enp4s0f1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq master mx-bond state UP mode DEFAULT group default qlen 1000
        link/ether 98:03:9b:9d:73:74 brd ff:ff:ff:ff:ff:ff permaddr 98:03:9b:9d:73:75 promiscuity 0 minmtu 68 maxmtu 9978
        bond_slave state BACKUP mii_status UP link_failure_count 0 perm_hwaddr 98:03:9b:9d:73:75 queue_id 0 addrgenmode eui64 numtxqueues 320 numrxqueues 40 gso_max_size 65536 gso_max_segs 65535 portname p1 switchid 74739d00039b0398
        vf 0     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking off, link-state disable, trust off, query_rss off
        vf 1     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking off, link-state disable, trust off, query_rss off
        vf 2     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking off, link-state disable, trust off, query_rss off
        vf 3     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking off, link-state disable, trust off, query_rss off
        vf 4     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking off, link-state disable, trust off, query_rss off
        vf 5     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking off, link-state disable, trust off, query_rss off
        vf 6     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking off, link-state disable, trust off, query_rss off
        vf 7     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking off, link-state disable, trust off, query_rss off
        vf 8     link/ether fa:16:3e:2a:d2:7f brd ff:ff:ff:ff:ff:ff, tx rate 999 (Mbps), max_tx_rate 999Mbps, spoof checking off, link-state disable, trust off, query_rss off
        vf 9     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking off, link-state disable, trust off, query_rss off

  • ML2/OVS

    루트 액세스를 사용하여 compute 노드에 로그인하고 물리적 브리지 인터페이스의 tc 규칙과 클래스를 표시합니다.

    예제

    #  tc class show dev mx-bond

    샘플 출력

    class htb 1:11 parent 1:fffe prio 0 rate 4Gbit ceil 34359Mbit burst 9000b cburst 8589b
    class htb 1:1 parent 1:fffe prio 0 rate 72Kbit ceil 34359Mbit burst 9063b cburst 8589b
    class htb 1:fffe root rate 34359Mbit ceil 34359Mbit burst 8589b cburst 8589b

추가 리소스

9.3.2. 최소 대역폭 QoS 정책을 사용하여 인스턴스 예약

포트에 최소 대역폭 QoS 정책을 적용하여 RHOSP(Red Hat OpenStack Platform) VM 인스턴스가 생성된 호스트에 최소 네트워크 대역폭이 있도록 할 수 있습니다.

사전 요구 사항

  • RHOSP Networking 서비스(neutron)에는 qosplacement 서비스 플러그인이 로드되어야 합니다. qos 서비스 플러그인은 기본적으로 로드됩니다.
  • 네트워킹 서비스에서 다음 API 확장을 지원해야 합니다.

    • agent-resources-synced
    • port-resource-request
    • qos-bw-minimum-ingress
  • ML2/OVS 또는 ML2/SR-IOV 메커니즘 드라이버를 사용해야 합니다.
  • 정책이 할당된 포트를 사용하는 인스턴스가 없는 경우에만 최소 대역폭 QoS 정책을 수정할 수 있습니다. 포트가 바인딩된 경우 네트워킹 서비스에서 배치 API 사용 정보를 업데이트할 수 없습니다.
  • 배치 서비스는 마이크로 버전 1.29를 지원해야 합니다.
  • Compute 서비스(nova)는 microversion 2.72를 지원해야 합니다.

절차

  1. 자격 증명 파일을 가져옵니다.

    예제

    $ source ~/overcloudrc

  2. Networking 서비스에 qos 서비스 플러그인이 로드되었는지 확인합니다.

    $ openstack network qos policy list

    qos 서비스 플러그인이 로드되지 않은 경우 ResourceNotFound 오류가 발생하고 계속하기 전에 qos 서비스 플러그인을 로드해야 합니다. 자세한 내용은 9.2절. “QoS 정책에 대한 네트워킹 서비스 구성”의 내용을 참조하십시오.

  3. QoS 정책을 생성할 프로젝트의 ID를 확인합니다.

    $ openstack project list

    샘플 출력

    +----------------------------------+----------+
    | ID                               | Name     |
    +----------------------------------+----------+
    | 4b0b98f8c6c040f38ba4f7146e8680f5 | auditors |
    | 519e6344f82e4c079c8e2eabb690023b | services |
    | 80bf5732752a41128e612fe615c886c6 | demo     |
    | 98a2f53c20ce4d50a40dac4a38016c69 | admin    |
    +----------------------------------+----------+

  4. 이전 단계의 프로젝트 ID를 사용하여 프로젝트에 대한 QoS 정책을 생성합니다.

    예제

    이 예에서는 admin 프로젝트에 대해 guaranteed_min_bw 라는 QoS 정책이 생성됩니다.

    $ openstack network qos policy create --share \
     --project 98a2f53c20ce4d50a40dac4a38016c69 guaranteed_min_bw
  5. 정책에 대한 규칙을 구성합니다.

    예제

    이 예에서는 guaranteed_min_bw 라는 정책에 대해 최소 대역폭이 40000000 kbps인 수신 및 송신에 대한 QoS 규칙이 생성됩니다.

    $ openstack network qos rule create \
     --type minimum-bandwidth --min-kbps 40000000 \
     --ingress guaranteed_min_bw
    $ openstack network qos rule create \
     --type minimum-bandwidth --min-kbps 40000000 \
     --egress guaranteed_min_bw
  6. 정책을 적용하도록 포트를 구성합니다.

    예제

    이 예에서 guaranteed_min_bw 정책은 포트 ID,ECDHE x9aiw1-2v74-144x-c2q8-ed8w423a6s12 에 적용됩니다.

    $ openstack port set --qos-policy guaranteed_min_bw \
     56x9aiw1-2v74-144x-c2q8-ed8w423a6s12

검증

  1. 언더클라우드 호스트에 stack 사용자로 로그인합니다.
  2. 언더클라우드 인증 정보 파일을 소싱합니다.

    $ source ~/stackrc
  3. 사용 가능한 리소스 공급자를 모두 나열합니다.

    $ openstack --os-placement-api-version 1.17 resource provider list

    샘플 출력

    +--------------------------------------+-----------------------------------------------------+------------+--------------------------------------+--------------------------------------+
    | uuid                                 | name                                                | generation | root_provider_uuid                   | parent_provider_uuid                 |
    +--------------------------------------+-----------------------------------------------------+------------+--------------------------------------+--------------------------------------+
    | 31d3d88b-bc3a-41cd-9dc0-fda54028a882 | dell-r730-014.localdomain                           |         28 | 31d3d88b-bc3a-41cd-9dc0-fda54028a882 | None                                 |
    | 6b15ddce-13cf-4c85-a58f-baec5b57ab52 | dell-r730-063.localdomain                           |         18 | 6b15ddce-13cf-4c85-a58f-baec5b57ab52 | None                                 |
    | e2f5082a-c965-55db-acb3-8daf9857c721 | dell-r730-063.localdomain:NIC Switch agent          |          0 | 6b15ddce-13cf-4c85-a58f-baec5b57ab52 | 6b15ddce-13cf-4c85-a58f-baec5b57ab52 |
    | d2fb0ef4-2f45-53a8-88be-113b3e64ba1b | dell-r730-014.localdomain:NIC Switch agent          |          0 | 31d3d88b-bc3a-41cd-9dc0-fda54028a882 | 31d3d88b-bc3a-41cd-9dc0-fda54028a882 |
    | f1ca35e2-47ad-53a0-9058-390ade93b73e | dell-r730-063.localdomain:NIC Switch agent:enp6s0f1 |         13 | 6b15ddce-13cf-4c85-a58f-baec5b57ab52 | e2f5082a-c965-55db-acb3-8daf9857c721 |
    | e518d381-d590-5767-8f34-c20def34b252 | dell-r730-014.localdomain:NIC Switch agent:enp6s0f1 |         19 | 31d3d88b-bc3a-41cd-9dc0-fda54028a882 | d2fb0ef4-2f45-53a8-88be-113b3e64ba1b |
    +--------------------------------------+-----------------------------------------------------+------------+--------------------------------------+--------------------------------------+

  4. 특정 리소스에서 제공하는 대역폭을 확인합니다.

    (undercloud)$ openstack --os-placement-api-version 1.17 \
     resource provider inventory list <rp_uuid>

    예제

    이 예에서 호스트 dell-r730-014 의 인터페이스 enp6s0f1 에 의해 제공되는 대역폭은 리소스 공급자 UUID, e518d381-d590-5767-8f34-c20def34b252 를 사용하여 확인됩니다.

    [stack@dell-r730-014 nova]$ openstack --os-placement-api-version 1.17 \
     resource provider inventory list e518d381-d590-5767-8f34-c20def34b252

    샘플 출력

    +----------------------------+------------------+----------+------------+----------+-----------+----------+
    | resource_class             | allocation_ratio | min_unit |   max_unit | reserved | step_size |    total |
    +----------------------------+------------------+----------+------------+----------+-----------+----------+
    | NET_BW_EGR_KILOBIT_PER_SEC |              1.0 |        1 | 2147483647 |        0 |         1 | 10000000 |
    | NET_BW_IGR_KILOBIT_PER_SEC |              1.0 |        1 | 2147483647 |        0 |         1 | 10000000 |
    +----------------------------+------------------+----------+------------+----------+-----------+----------+

  5. 인스턴스가 실행 중인 경우 리소스 공급자에 대한 클레임을 확인하려면 다음 명령을 실행합니다.

    (undercloud)$ openstack --os-placement-api-version 1.17 \
     resource provider show --allocations  <rp_uuid>

    예제

    이 예에서 리소스 공급자에 대한 클레임은 리소스 공급자 UUID, e518d381 - d590-5767-8f34-c20def34b252 를 사용하여 호스트에서 확인됩니다.

    [stack@dell-r730-014 nova]$ openstack --os-placement-api-version 1.17 resource provider show --allocations  e518d381-d590-5767-8f34-c20def34b252 -f value -c allocations

    샘플 출력

    {3cbb9e07-90a8-4154-8acd-b6ec2f894a83: {resources: {NET_BW_EGR_KILOBIT_PER_SEC: 1000000, NET_BW_IGR_KILOBIT_PER_SEC: 1000000}}, 8848b88b-4464-443f-bf33-5d4e49fd6204: {resources: {NET_BW_EGR_KILOBIT_PER_SEC: 1000000, NET_BW_IGR_KILOBIT_PER_SEC: 1000000}}, 9a29e946-698b-4731-bc28-89368073be1a: {resources: {NET_BW_EGR_KILOBIT_PER_SEC: 1000000, NET_BW_IGR_KILOBIT_PER_SEC: 1000000}}, a6c83b86-9139-4e98-9341-dc76065136cc: {resources: {NET_BW_EGR_KILOBIT_PER_SEC: 3000000, NET_BW_IGR_KILOBIT_PER_SEC: 3000000}}, da60e33f-156e-47be-a632-870172ec5483: {resources: {NET_BW_EGR_KILOBIT_PER_SEC: 1000000, NET_BW_IGR_KILOBIT_PER_SEC: 1000000}}, eb582a0e-8274-4f21-9890-9a0d55114663: {resources: {NET_BW_EGR_KILOBIT_PER_SEC: 3000000, NET_BW_IGR_KILOBIT_PER_SEC: 3000000}}}

추가 리소스

9.4. QoS 정책을 사용하여 네트워크 트래픽 제한

RHOSP 네트워크, 포트 또는 유동 IP의 대역폭을 제한하는 RHOSP(Red Hat OpenStack Platform) 네트워킹 서비스(neutron) 서비스 품질(neutron) 정책을 생성하고 지정된 속도를 초과하는 모든 트래픽을 삭제할 수 있습니다.

사전 요구 사항

  • Networking 서비스에 qos 서비스 플러그인이 로드되어야 합니다. (기본적으로 플러그인이 로드됩니다.)

절차

  1. 자격 증명 파일을 가져옵니다.

    예제

    $ source ~/overcloudrc

  2. Networking 서비스에 qos 서비스 플러그인이 로드되었는지 확인합니다.

    $ openstack network qos policy list

    qos 서비스 플러그인이 로드되지 않은 경우 ResourceNotFound 오류가 발생하고 계속하기 전에 qos 서비스 플러그인을 로드해야 합니다. 자세한 내용은 9.2절. “QoS 정책에 대한 네트워킹 서비스 구성”의 내용을 참조하십시오.

  3. QoS 정책을 생성할 프로젝트의 ID를 확인합니다.

    $ openstack project list

    샘플 출력

    +----------------------------------+----------+
    | ID                               | Name     |
    +----------------------------------+----------+
    | 4b0b98f8c6c040f38ba4f7146e8680f5 | auditors |
    | 519e6344f82e4c079c8e2eabb690023b | services |
    | 80bf5732752a41128e612fe615c886c6 | demo     |
    | 98a2f53c20ce4d50a40dac4a38016c69 | admin    |
    +----------------------------------+----------+

  4. 이전 단계의 프로젝트 ID를 사용하여 프로젝트에 대한 QoS 정책을 생성합니다.

    예제

    이 예제에서는 admin 프로젝트에 대해 bw-limiter 라는 QoS 정책이 생성됩니다.

    $ openstack network qos policy create --share --project 98a2f53c20ce4d50a40dac4a38016c69 bw-limiter
  5. 정책에 대한 규칙을 구성합니다.

    참고

    각 규칙의 유형 또는 방향이 다른 경우 정책에 둘 이상의 규칙을 추가할 수 있습니다. 예를 들어 송신이 있는 두 개의 대역폭 제한 규칙과 수신 방향이 있는 규칙을 지정할 수 있습니다.

    예제

    이 예에서는 대역폭 제한이 50000 kbps이고 최대 burst 크기는 50000 kbps인 bw-limiter 라는 정책에 대해 QoS 수신 및 송신 규칙이 생성됩니다.

    $ openstack network qos rule create --type bandwidth-limit \
        --max-kbps 50000 --max-burst-kbits 50000 --ingress bw-limiter
    
    $ openstack network qos rule create --type bandwidth-limit \
        --max-kbps 50000 --max-burst-kbits 50000 --egress bw-limiter
  6. 정책이 연결된 정책을 사용하여 포트를 생성하거나 정책을 기존 포트에 연결할 수 있습니다.

    예 - 정책이 연결된 포트 생성

    이 예에서 정책 bw-limiter 는 포트 포트2 와 연결되어 있습니다.

    $ openstack port create --qos-policy bw-limiter --network private port2

    샘플 출력

    +-----------------------+--------------------------------------------------+
    | Field                 | Value                                            |
    +-----------------------+--------------------------------------------------+
    | admin_state_up        | UP                                               |
    | allowed_address_pairs |                                                  |
    | binding_host_id       |                                                  |
    | binding_profile       |                                                  |
    | binding_vif_details   |                                                  |
    | binding_vif_type      | unbound                                          |
    | binding_vnic_type     | normal                                           |
    | created_at            | 2022-07-04T19:20:24Z                             |
    | data_plane_status     | None                                             |
    | description           |                                                  |
    | device_id             |                                                  |
    | device_owner          |                                                  |
    | dns_assignment        | None                                             |
    | dns_name              | None                                             |
    | extra_dhcp_opts       |                                                  |
    | fixed_ips             | ip_address='192.0.2.210', subnet_id='292f8c-...' |
    | id                    | f51562ee-da8d-42de-9578-f6f5cb248226             |
    | ip_address            | None                                             |
    | mac_address           | fa:16:3e:d9:f2:ba                                |
    | name                  | port2                                            |
    | network_id            | 55dc2f70-0f92-4002-b343-ca34277b0234             |
    | option_name           | None                                             |
    | option_value          | None                                             |
    | port_security_enabled | False                                            |
    | project_id            | 98a2f53c20ce4d50a40dac4a38016c69                 |
    | qos_policy_id         | 8491547e-add1-4c6c-a50e-42121237256c             |
    | revision_number       | 6                                                |
    | security_group_ids    | 0531cc1a-19d1-4cc7-ada5-49f8b08245be             |
    | status                | DOWN                                             |
    | subnet_id             | None                                             |
    | tags                  | []                                               |
    | trunk_details         | None                                             |
    | updated_at            | 2022-07-04T19:23:00Z                             |
    +-----------------------+--------------------------------------------------+

    예 - 기존 포트에 정책 연결

    이 예에서 정책 bw-limiterport1 과 연결되어 있습니다.

    $ openstack port set --qos-policy bw-limiter port1

검증

  • bandwidthwith limit 정책이 포트에 적용되는지 확인합니다.

    • 정책 ID를 가져옵니다.

      예제

      이 예에서는 QoS 정책 bw-limiter 가 쿼리됩니다.

      $ openstack network qos policy show bw-limiter

      샘플 출력

      +-------------------+-------------------------------------------------------------------+
      | Field             | Value                                                             |
      +-------------------+-------------------------------------------------------------------+
      | description       |                                                                   |
      | id                | 8491547e-add1-4c6c-a50e-42121237256c                              |
      | is_default        | False                                                             |
      | name              | bw-limiter                                                        |
      | project_id        | 98a2f53c20ce4d50a40dac4a38016c69                                  |
      | revision_number   | 4                                                                 |
      | rules             | [{u'max_kbps': 50000, u'direction': u'egress',                    |
      |                   |   u'type': u'bandwidth_limit',                                    |
      |                   |   u'id': u'0db48906-a762-4d32-8694-3f65214c34a6',                 |
      |                   |   u'max_burst_kbps': 50000,                                       |
      |                   |   u'qos_policy_id': u'8491547e-add1-4c6c-a50e-42121237256c'},     |
      |                   | [{u'max_kbps': 50000, u'direction': u'ingress',                   |
      |                   |   u'type': u'bandwidth_limit',                                    |
      |                   |   u'id': u'faabef24-e23a-4fdf-8e92-f8cb66998834',                 |
      |                   |   u'max_burst_kbps': 50000,                                       |
      |                   |   u'qos_policy_id': u'8491547e-add1-4c6c-a50e-42121237256c'}]     |
      | shared            | False                                                             |
      +-------------------+-------------------------------------------------------------------+

    • 포트를 쿼리하고 정책 ID가 이전 단계에서 가져온 것과 일치하는지 확인합니다.

      예제

      이 예에서는 port1 이 쿼리됩니다.

      $ openstack port show port1

      샘플 출력

      +-------------------------+--------------------------------------------------------------------+
      | Field                   | Value                                                              |
      +-------------------------+--------------------------------------------------------------------+
      | admin_state_up          | UP                                                                 |
      | allowed_address_pairs   | ip_address='192.0.2.128', mac_address='fa:16:3e:e1:eb:73'          |
      | binding_host_id         | compute-2.redhat.local                                             |
      | binding_profile         |                                                                    |
      | binding_vif_details     | port_filter='True'                                                 |
      | binding_vif_type        | ovs                                                                |
      | binding_vnic_type       | normal                                                             |
      | created_at              | 2022-07-04T19:07:56                                                |
      | data_plane_status       | None                                                               |
      | description             |                                                                    |
      | device_id               | 53abd2c4-955d-4b44-b6ad-f106e3f15df0                               |
      | device_owner            | compute:nova                                                       |
      | dns_assignment          | fqdn='host-192-0-2-213.openstacklocal.', hostname='my-host3',      |
      |                         | ip_address='192.0.2.213'                                           |
      | dns_domain              | None                                                               |
      | dns_name                |                                                                    |
      | extra_dhcp_opts         |                                                                    |
      | fixed_ips               | ip_address='192.0.2..213', subnet_id='641d1db2-3b40-437b-b87b-63   |
      |                         | 079a7063ca'                                                        |
      |                         | ip_address='2001:db8:0:f868:f816:3eff:fee1:eb73', subnet_id='c7ed0 |
      |                         | 70a-d2ee-4380-baab-6978932a7dcc'                                   |
      | id                      | 56x9aiw1-2v74-144x-c2q8-ed8w423a6s12                               |
      | location                | cloud='', project.domain_id=, project.domain_name=, project.id='7c |
      |                         | b99d752fdb4944a2208ec9ee019226', project.name=, region_name='regio |
      |                         | nOne', zone=                                                       |
      | mac_address             | fa:16:3e:e1:eb:73                                                  |
      | name                    | port2                                                              |
      | network_id              | 55dc2f70-0f92-4002-b343-ca34277b0234                               |
      | port_security_enabled   | True                                                               |
      | project_id              | 98a2f53c20ce4d50a40dac4a38016c69                                   |
      | propagate_uplink_status | None                                                               |
      | qos_policy_id           | 8491547e-add1-4c6c-a50e-42121237256c                               |
      | resource_request        | None                                                               |
      | revision_number         | 6                                                                  |
      | security_group_ids      | 4cdeb836-b5fd-441e-bd01-498d758704fd                               |
      | status                  | ACTIVE                                                             |
      | tags                    |                                                                    |
      | trunk_details           | None                                                               |
      | updated_at              | 2022-07-04T19:11:41Z                                               |
      +-------------------------+--------------------------------------------------------------------+

추가 리소스

9.5. QoS 정책을 표시하는 DestinationRuleP를 사용하여 네트워크 트래픽 우선순위 지정

IP 헤더에 관련 값을 포함시켜 RHOSP(Red Hat OpenStack Platform) 네트워크에 QoS(Quality of Service) 정책을 구현할 수 있습니다. RHOSP Networking 서비스(neutron) QoS 정책은 DestinationRuleP 표시를 사용하여 중성자 포트 및 네트워크에서 송신 트래픽만 관리할 수 있습니다.

사전 요구 사항

  • Networking 서비스에 qos 서비스 플러그인이 로드되어야 합니다. (기본값입니다.)
  • ML2/OVS 또는 ML2/OVN 메커니즘 드라이버를 사용해야 합니다.

절차

  1. 자격 증명 파일을 가져옵니다.

    예제

    $ source ~/overcloudrc

  2. Networking 서비스에 qos 서비스 플러그인이 로드되었는지 확인합니다.

    $ openstack network qos policy list

    qos 서비스 플러그인이 로드되지 않은 경우 ResourceNotFound 오류가 발생하고 계속 진행하기 전에 Networking 서비스를 구성해야 합니다. 자세한 내용은 9.2절. “QoS 정책에 대한 네트워킹 서비스 구성”의 내용을 참조하십시오.

  3. QoS 정책을 생성할 프로젝트의 ID를 확인합니다.

    $ openstack project list

    샘플 출력

    +----------------------------------+----------+
    | ID                               | Name     |
    +----------------------------------+----------+
    | 4b0b98f8c6c040f38ba4f7146e8680f5 | auditors |
    | 519e6344f82e4c079c8e2eabb690023b | services |
    | 80bf5732752a41128e612fe615c886c6 | demo     |
    | 98a2f53c20ce4d50a40dac4a38016c69 | admin    |
    +----------------------------------+----------+

  4. 이전 단계의 프로젝트 ID를 사용하여 프로젝트에 대한 QoS 정책을 생성합니다.

    예제

    이 예에서는 admin 프로젝트에 대해 qos-web-servers 라는 QoS 정책이 생성됩니다.

    openstack network qos policy create --project 98a2f53c20ce4d50a40dac4a38016c69 qos-web-servers
  5. DestinationRuleP 규칙을 생성하여 정책에 적용합니다.

    예제

    이 예에서는 DestinationRuleP 마크 18 을 사용하여 DestinationRuleP 규칙이 생성되며 qos-web-servers 정책에 적용됩니다.

    openstack network qos rule create --type dscp-marking --dscp-mark 18 qos-web-servers

    샘플 출력

    Created a new dscp_marking_rule:
    +-----------+--------------------------------------+
    | Field     | Value                                |
    +-----------+--------------------------------------+
    | dscp_mark | 18                                   |
    | id        | d7f976ec-7fab-4e60-af70-f59bf88198e6 |
    +-----------+--------------------------------------+

  6. 규칙에 할당된ECDHEP 값을 변경할 수 있습니다.

    예제

    이 예에서 qos-web-servers 정책에서 d7f976ec-7fab-4e60-af70-f59bf88198e6 규칙에 대해 DestinationRuleP 마크 값이 22로 변경됩니다.

    $ openstack network qos rule set --dscp-mark 22 qos-web-servers d7f976ec-7fab-4e60-af70-f59bf88198e6
  7. DestinationRuleP 규칙을 삭제할 수 있습니다.

    예제

    이 예에서는 qos-web-servers 정책의 d7f976ec-7fab-4e60-af70-f59bf88198e6 이 삭제됩니다.

    $ openstack network qos rule delete qos-web-servers d7f976ec-7fab-4e60-af70-f59bf88198e6

검증

  • DestinationRuleP 규칙이 QoS 정책에 적용되는지 확인합니다.

    예제

    이 예제에서는 d7f976ec-7fab-4e60-af70-f59bf88198e6 이 QoS 정책 qos-web-servers 에 적용됩니다.

    $ openstack network qos rule list qos-web-servers

    샘플 출력

    +-----------+--------------------------------------+
    | dscp_mark | id                                   |
    +-----------+--------------------------------------+
    |        18 | d7f976ec-7fab-4e60-af70-f59bf88198e6 |
    +-----------+--------------------------------------+

추가 리소스

9.6. 네트워킹 서비스 RBAC를 사용하여 프로젝트에 QoS 정책 적용

RHOSP(Red Hat OpenStack Platform) 네트워킹 서비스(neutron)를 사용하면 QoS(Quality of Service) 정책에 대한 RBAC(역할 기반 액세스 제어)를 추가할 수 있습니다. 결과적으로 개별 프로젝트에 QoS 정책을 적용할 수 있습니다.

전제 조건

  • 사용 가능한 QoS 정책이 하나 이상 있어야 합니다.

절차

  • 특정 QoS 정책과 관련된 RHOSP Networking 서비스 RBAC 정책을 생성하여 특정 프로젝트에 할당합니다.

    $ openstack network rbac create --type qos_policy --target-project <project_name | project_ID> --action access_as_shared <QoS_policy_name | QoS_policy_ID>

    예제

    예를 들어, B w-limiter 라는 우선순위가 낮은 네트워크 트래픽을 허용하는 QoS 정책이 있을 수 있습니다. RHOSP Networking 서비스 RBAC 정책을 사용하면 특정 프로젝트에 QoS 정책을 적용할 수 있습니다.

    $ openstack network rbac create --type qos_policy --target-project 80bf5732752a41128e612fe615c886c6 --action access_as_shared bw-limiter

10장. 브릿지 매핑 구성

RHOSP(Red Hat OpenStack Platform)에서 브리지 매핑은 물리적 네트워크 이름(interface 레이블)을 Modular Layer 2 플러그인 메커니즘 드라이버 Open vSwitch(OVS) 또는 OVN(Open Virtual Network)으로 만든 브리지에 연결합니다. RHOSP Networking 서비스(neutron)는 브리지 매핑을 사용하여 공급자 네트워크 트래픽이 물리적 네트워크에 도달할 수 있도록 합니다.

이 섹션에 포함된 항목은 다음과 같습니다.

10.1. 브리지 매핑 개요

RHOSP(Red Hat OpenStack Platform) 네트워킹 서비스(neutron)에서는 브리지 매핑을 사용하여 공급자 네트워크 트래픽이 물리적 네트워크에 도달할 수 있도록 합니다. 트래픽은 라우터의 qg-xxx 인터페이스에서 공급자 네트워크를 벗어나 중간 브릿지(br-int)에 도달합니다.

데이터 경로의 다음 부분은 배포에서 사용하는 메커니즘에 따라 다릅니다.

  • ML2/OVS: br-intbr-ex 간의 패치 포트를 통해 트래픽이 공급자 네트워크의 브리지를 통해 물리적 네트워크로 전달할 수 있습니다.
  • ML2/OVN: Networking 서비스는 하이퍼바이저에 바인딩된 VM이 있고 VM에 포트가 필요한 경우에만 하이퍼바이저에 패치 포트를 생성합니다.

라우터가 예약된 네트워크 노드에서 브리지 매핑을 구성합니다. 라우터 트래픽은 공급자 네트워크에 표시된 대로 올바른 물리적 네트워크를 사용하여 송신할 수 있습니다.

참고

네트워킹 서비스는 각 물리적 네트워크에 대해 하나의 브릿지만 지원합니다. 두 개 이상의 물리적 네트워크를 동일한 브릿지에 매핑하지 마십시오.

10.2. 트래픽 흐름

각 외부 네트워크는 qg-xxx 라우터에 태그된 내부 VLAN ID로 표시됩니다. 패킷이 phy-br-ex 에 도달하면 br-ex 포트는 VLAN 태그를 제거하고 패킷을 물리적 인터페이스로 이동한 다음 외부 네트워크로 이동합니다.

외부 네트워크의 반환 패킷은 br-ex 에 도착하고 phy-br-ex <-> int-br-ex 를 사용하여 br-int 로 이동합니다. 패킷이 br-ex 를 통해 br-int 로 전송되면 패킷의 외부 VLAN ID가 br-int 의 내부 VLAN 태그로 교체되고 qg-xxx 에서 패킷을 수락할 수 있습니다.

송신 패킷의 경우 패킷의 내부 VLAN 태그는 br-ex 의 외부 VLAN 태그(또는 NeutronNetworkVLANRanges 매개변수에 정의된 외부 브리지)로 교체됩니다.

10.3. 브릿지 매핑 구성

RHOSP(Red Hat OpenStack Platform) Networking 서비스(neutron)에서 실제 네트워크와 공급자 네트워크 트래픽을 연결하는 데 사용하는 브리지 매핑을 수정하려면 필요한 heat 매개변수를 수정하고 오버클라우드를 다시 배포합니다.

사전 요구 사항

  • stack 사용자로 underclod 호스트에 액세스할 수 있어야 합니다.
  • 라우터가 예약된 네트워크 노드에서 브리지 매핑을 구성해야 합니다.
  • 컴퓨팅 노드에 대한 브리지 매핑도 구성해야 합니다.

절차

  1. 언더클라우드 호스트에 stack 사용자로 로그인합니다.
  2. 언더클라우드 인증 정보 파일을 소싱합니다.

    $ source ~/stackrc
  3. 사용자 지정 YAML 환경 파일을 생성합니다.

    예제

    $ vi /home/stack/templates/my_bridge_mappings.yaml

  4. 환경 파일에는 parameter_defaults 키워드가 포함되어야 합니다. parameter_defaults 키워드 뒤의 사이트에 적합한 값과 함께 NeutronBridgeMappings heat 매개변수를 추가합니다.

    예제

    이 예제에서 NeutronBridgeMappings 매개변수는 물리적 이름인 datacentre테넌트, 브리지 br-exbr-tenant 를 각각 연결합니다.

    parameter_defaults:
      NeutronBridgeMappings: "datacentre:br-ex,tenant:br-tenant"
    참고

    NeutronBridgeMappings 매개변수를 사용하지 않으면 기본값은 호스트(br-ex)의 외부 브릿지를 물리 이름(datacentre)에 매핑합니다.

  5. 플랫 네트워크를 사용하는 경우 NeutronFlatNetworks 매개변수를 사용하여 이름을 추가합니다.

    예제

    이 예제에서 매개변수는 물리적 이름 datacentre 를 브리지 br-ex, 물리적 이름 테넌트 와 브리지 br-tenant와 연결합니다.

    parameter_defaults:
      NeutronBridgeMappings: "datacentre:br-ex,tenant:br-tenant"
      NeutronFlatNetworks: "my_flat_network"
    참고

    NeutronFlatNetworks 매개변수를 사용하지 않는 경우 기본값은 datacentre 입니다.

  6. VLAN 네트워크를 사용하는 경우 NeutronNetworkVLANRanges 매개변수를 사용하여 액세스하는 VLAN 범위와 함께 네트워크 이름을 지정합니다.

    예제

    이 예제에서 NeutronNetworkVLANRanges 매개변수는 테넌트 네트워크에 대해 1~1000 의 VLAN 범위를 지정합니다.

    parameter_defaults:
     NeutronBridgeMappings: "datacentre:br-ex,tenant:br-tenant"
     NeutronNetworkVLANRanges: "tenant:1:1000"
  7. 배포 명령을 실행하고 코어 heat 템플릿, 환경 파일 및 이 새로운 사용자 지정 환경 파일을 포함합니다.

    $ openstack overcloud deploy --templates \
      -e <your_environment_files> \
      -e /home/stack/templates/my_bridge_mappings.yaml
  8. 다음 단계를 수행합니다.

    1. 네트워크 VLAN 범위를 사용하여 해당 외부 네트워크를 나타내는 공급자 네트워크를 생성합니다. ( neutron 공급자 네트워크 또는 유동 IP 네트워크를 생성할 때 물리적 이름을 사용합니다.)
    2. 라우터 인터페이스를 사용하여 외부 네트워크를 프로젝트 네트워크에 연결합니다.

추가 리소스

10.4. OVS에 대한 브리지 매핑 유지

OVS 브리지 매핑을 제거한 후 후속 정리를 수행하여 브리지 구성이 연결된 패치 포트 항목을 지워야 합니다. 다음과 같은 방법으로 이 작업을 수행할 수 있습니다.

  • 수동 포트 정리 - 과도한 패치 포트를 신중하게 제거해야 합니다. 네트워크 연결 중단이 필요하지 않습니다.
  • 자동화된 포트 정리 - 자동 정리 작업을 수행하지만 중단이 필요하므로 필요한 브릿지 매핑을 다시 추가해야 합니다. 네트워크 연결이 중단될 수 있는 경우 예약된 유지 관리 기간 동안 이 옵션을 선택합니다.
참고

OVN 브리지 매핑이 제거되면 OVN 컨트롤러는 연결된 모든 패치 포트를 자동으로 정리합니다.

10.4.1. OVS 패치 포트 수동 정리

OVS 브리지 매핑을 제거한 후 연결된 패치 포트도 제거해야 합니다.

사전 요구 사항

  • 정리 중인 패치 포트는 OVS(Open Virtual Switch) 포트여야 합니다.
  • 수동 패치 포트 정리를 수행하는 데 시스템 중단이 필요하지 않습니다.
  • 이름 지정 규칙에 따라 정리할 패치 포트를 식별할 수 있습니다.

    • br-$external_bridge 패치 포트는 phy -<external 브리지 이름&gt;(예: phy-br-ex2)입니다.
    • br-int 패치 포트의 이름은 int-<external 브리지 name&gt;(예: int-br-ex2)입니다.

절차

  1. ovs-vsctl 을 사용하여 제거된 브리지 매핑 항목과 연결된 OVS 패치 포트를 제거합니다.

    # ovs-vsctl del-port br-ex2 datacentre
    # ovs-vsctl del-port br-tenant tenant
  2. neutron-openvswitch-agent 를 다시 시작합니다.

    # service neutron-openvswitch-agent restart

10.4.2. OVS 패치 포트 자동 정리

OVS 브리지 매핑을 제거한 후 연결된 패치 포트도 제거해야 합니다.

참고

OVN 브리지 매핑이 제거되면 OVN 컨트롤러는 연결된 모든 패치 포트를 자동으로 정리합니다.

사전 요구 사항

  • 정리 중인 패치 포트는 OVS(Open Virtual Switch) 포트여야 합니다.
  • neutron-ovs-cleanup 명령을 사용하여 패치 포트를 자동으로 정리하면 네트워크 연결이 중단되고 예약된 유지 관리 기간 중에만 수행해야 합니다.
  • --ovs_all_ports 플래그를 사용하여 br-int 에서 모든 패치 포트를 제거하고, 터널을 br-tun 에서 정리한 후 브리지에서 브리지로 패치 포트를 정리합니다.
  • neutron-ovs-cleanup 명령은 모든 OVS 브리지의 모든 패치 포트(인스턴스, qdhcp/qrouter 등)를 분리합니다.

절차

  1. --ovs_all_ports 플래그를 사용하여 neutron-ovs-cleanup 명령을 실행합니다.

    중요

    이 단계를 수행하면 전체 네트워크 중단이 발생합니다.

    # /usr/bin/neutron-ovs-cleanup
    --config-file /etc/neutron/plugins/ml2/openvswitch_agent.ini
    --log-file /var/log/neutron/ovs-cleanup.log --ovs_all_ports
  2. 오버클라우드를 재배포하여 연결을 복원합니다.

    openstack overcloud deploy 명령을 재실행하면 브리지 매핑 값이 다시 적용됩니다.

    참고

    다시 시작한 후 OVS 에이전트는 bridge_mappings에 없는 연결을 방해하지 않습니다. 따라서 br-intbr-ex2 에 연결되어 있고 br-ex2 에 일부 흐름이 있는 경우 bridge_mappings 구성에서 br-int 를 제거하면 OVS 에이전트 또는 노드를 다시 시작할 때 두 브리지가 분리되지 않습니다.

추가 리소스

11장. VLAN 인식 인스턴스

11.1. VLAN 트렁크 및 VLAN 투명 네트워크

VM 인스턴스는 단일 가상 NIC를 통해 VLAN 태그된 트래픽을 보내고 수신할 수 있습니다. 이는 VLAN 태그 지정된 트래픽을 예상하는 NFV 애플리케이션(VNF)에 특히 유용하므로 단일 가상 NIC가 여러 고객 또는 서비스를 제공할 수 있습니다.

ML2/OVN 배포에서 VLAN 투명 네트워크를 사용하여 VLAN 인식 인스턴스를 지원할 수 있습니다. ML2/OVN 또는 ML2/OVS 배포의 대안으로 트렁크를 사용하여 VLAN 인식 인스턴스를 지원할 수 있습니다.

VLAN 투명한 네트워크에서 VM 인스턴스에 VLAN 태그를 설정합니다. VLAN 태그는 네트워크를 통해 전송되며 동일한 VLAN의 인스턴스에서 사용하며 다른 인스턴스 및 장치에서 무시합니다. VLAN 투명 네트워크에서 VLAN은 인스턴스에서 관리됩니다. OpenStack Networking 서비스(neutron)에서 VLAN을 설정할 필요가 없습니다.

VLAN 트렁크는 VLAN을 단일 트렁크 포트에 결합하여 VLAN 인식 인스턴스를 지원합니다. 예를 들어 프로젝트 데이터 네트워크는 VLAN 또는 터널링(VXLAN, GRE 또는 Geneve) 분할을 사용할 수 있지만 인스턴스는 VLAN ID로 태그가 지정된 트래픽을 볼 수 있습니다. 네트워크 패킷은 인스턴스에 삽입되기 직전에 태그를 지정하고 전체 네트워크 전체에서 태그를 지정할 필요가 없습니다.

다음 표에서는 VLAN 투명한 네트워크 및 VLAN 트렁크의 특정 기능을 비교합니다.

 투명 (Transparent)트렁크

메커니즘 드라이버 지원

ML2/OVN

ML2/OVN, ML2/OVS

에서 관리하는 VLAN 설정

VM 인스턴스

OpenStack Networking 서비스(neutron)

IP 할당

VM 인스턴스에 구성

DHCP에서 할당

VLAN ID

유연하게 사용할 수 있습니다. 인스턴스에서 VLAN ID를 설정할 수 있습니다.

설정되어 있습니다. 인스턴스는 트렁크에 구성된 VLAN ID를 사용해야 합니다.

11.2. ML2/OVN 배포에서 VLAN 투명성 활성화

VLAN 태그된 트래픽을 VM(가상 머신) 인스턴스 간에 보내야 하는 경우 VLAN 투명성을 활성화합니다. VLAN 투명 네트워크에서 neutron에서 구성하지 않고 VM에서 VLANS를 직접 구성할 수 있습니다.

사전 요구 사항

  • 메커니즘 드라이버로 ML2/OVN을 사용하여 Red Hat OpenStack Platform 16.1 이상 배포.
  • VLAN 또는 Geneve 유형의 공급자 네트워크. 플랫 유형 공급자 네트워크로 배포 시 VLAN 투명성을 사용하지 마십시오.
  • 외부 스위치가 두 VLAN 모두에서 ethertype 0x8100을 사용하여 802.1q VLAN을 지원하는지 확인합니다. OVN VLAN 투명도는 외부 공급자 VLAN 이더넷8 또는 0x9100으로 설정된 802.1ad QinQ를 지원하지 않습니다.

절차

  1. 언더클라우드 노드의 환경 파일에서 EnableVLANTransparency 매개변수를 true 로 설정합니다. 예를 들어 ovn-extras.yaml 에 다음 행을 추가합니다.

    parameter_defaults:
        EnableVLANTransparency: true
  2. openstack overcloud deploy 명령에 환경 파일을 해당 환경과 관련된 기타 환경 파일과 함께 추가하고 오버클라우드를 배포합니다.

    $ openstack overcloud deploy \
    --templates \
    …
    -e <other_overcloud_environment_files> \
    
    -e ovn-extras.yaml \
    …

    <other_overcloud_environment_files> 를 기존 배포의 일부인 환경 파일 목록으로 바꿉니다.

  3. --transparent-vlan 인수를 사용하여 네트워크를 만듭니다.

    예제

    $ openstack network create network-name --transparent-vlan

  4. 참여 VM마다 VLAN 인터페이스를 설정합니다.

    VLAN 투명성에 필요한 추가 태그 지정을 수용하려면 인터페이스 MTU를 underlay 네트워크의 MTU보다 4바이트 미만으로 설정합니다. 예를 들어, underlay 네트워크 MTU가 1500인 경우 인터페이스 MTU를 1496로 설정합니다.

    다음 예제 명령은 eth0 에 MTU가 1496인 VLAN 인터페이스를 추가합니다. VLAN은 50이고 인터페이스 이름은 vlan50 입니다.

    예제

    $ ip link add link eth0 name vlan50 type vlan id 50 mtu 1496
    $ ip link set vlan50 up
    $ ip addr add 192.128.111.3/24 dev vlan50

  5. VM 포트에서 --allowed-address 를 설정합니다.

    4단계의 VM 내부에 VLAN 인터페이스에서 생성한 IP 주소로 허용되는 주소를 설정합니다. 선택적으로 VLAN 인터페이스 MAC 주소를 설정할 수도 있습니다.

    예제

    다음 예제에서는 fv82gwk3-qq2e-yu93-go31-56w7sf 4에서 선택적 MAC 주소 00:40:96:a8:45:c4 를 사용하여 IP 주소를 192.128.111.3 로 설정합니다.

    $ openstack port set --allowed-address ip-address=192.128.111.3,mac-address=00:40:96:a8:45:c4 fv82gwk3-qq2e-yu93-go31-56w7sf476mm0

검증

  1. vlan50 IP 주소를 사용하여 VLAN의 두 VM 간 을 ping합니다.
  2. eth0 에서 tcpdump 를 사용하여 패킷이 VLAN 태그가 변경되지 않았는지 확인합니다.

추가 리소스

11.3. 트렁크 플러그인 검토

Red Hat OpenStack 배포 중에 트렁크 플러그인이 기본적으로 활성화됩니다. 컨트롤러 노드에서 구성을 검토할 수 있습니다.

  • 컨트롤러 노드에서 /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf 파일에서 트렁크 플러그인이 활성화되어 있는지 확인합니다.

    service_plugins=router,qos,trunk

11.4. 트렁크 연결 생성

VLAN 태그 지정된 트래픽에 대한 트렁크를 구현하려면 상위 포트를 생성하고 기존 neutron 네트워크에 새 포트를 연결합니다. 새 포트를 연결하면 OpenStack Networking에서 생성한 상위 포트에 트렁크 연결을 추가합니다. 다음으로 하위 포트를 생성합니다. 이러한 하위 포트는 VLAN을 인스턴스에 연결하여 트렁크에 연결할 수 있습니다. 인스턴스 운영 체제 내에서 하위 포트에 연결된 VLAN의 트래픽을 태그하는 하위 인터페이스도 생성해야 합니다.

  1. 트렁크된 VLAN에 액세스해야 하는 인스턴스가 포함된 네트워크를 식별합니다. 이 예제에서는 공용 네트워크입니다.

    openstack network list
    +--------------------------------------+---------+--------------------------------------+
    | ID                                   | Name    | Subnets                              |
    +--------------------------------------+---------+--------------------------------------+
    | 82845092-4701-4004-add7-838837837621 | private | 434c7982-cd96-4c41-a8c9-b93adbdcb197 |
    | 8d8bc6d6-5b28-4e00-b99e-157516ff0050 | public  | 3fd811b4-c104-44b5-8ff8-7a86af5e332c |
    +--------------------------------------+---------+--------------------------------------+
  2. 상위 트렁크 포트를 생성하여 인스턴스가 연결하는 네트워크에 연결합니다. 이 예에서는 공용 네트워크에서 parent-trunk-port라는 neutron 포트를 생성합니다. 이 트렁크는 하위 포트를 생성하는 데 사용할 수 있으므로 상위 포트입니다.

    openstack port create --network public parent-trunk-port
    +-----------------------+-----------------------------------------------------------------------------+
    | Field                 | Value                                                                       |
    +-----------------------+-----------------------------------------------------------------------------+
    | admin_state_up        | UP                                                                          |
    | allowed_address_pairs |                                                                             |
    | binding_host_id       |                                                                             |
    | binding_profile       |                                                                             |
    | binding_vif_details   |                                                                             |
    | binding_vif_type      | unbound                                                                     |
    | binding_vnic_type     | normal                                                                      |
    | created_at            | 2016-10-20T02:02:33Z                                                        |
    | description           |                                                                             |
    | device_id             |                                                                             |
    | device_owner          |                                                                             |
    | extra_dhcp_opts       |                                                                             |
    | fixed_ips             | ip_address='172.24.4.230', subnet_id='dc608964-9af3-4fed-9f06-6d3844fb9b9b' |
    | headers               |                                                                             |
    | id                    | 20b6fdf8-0d43-475a-a0f1-ec8f757a4a39                                        |
    | mac_address           | fa:16:3e:33:c4:75                                                           |
    | name                  | parent-trunk-port                                                           |
    | network_id            | 871a6bd8-4193-45d7-a300-dcb2420e7cc3                                        |
    | project_id            | 745d33000ac74d30a77539f8920555e7                                            |
    | project_id            | 745d33000ac74d30a77539f8920555e7                                            |
    | revision_number       | 4                                                                           |
    | security_groups       | 59e2af18-93c6-4201-861b-19a8a8b79b23                                        |
    | status                | DOWN                                                                        |
    | updated_at            | 2016-10-20T02:02:33Z                                                        |
    +-----------------------+-----------------------------------------------------------------------------+
  3. 2단계에서 만든 포트를 사용하여 트렁크를 만듭니다. 이 예에서 트렁크의 이름은 parent-trunk 입니다.

    openstack network trunk create --parent-port parent-trunk-port parent-trunk
    +-----------------+--------------------------------------+
    | Field           | Value                                |
    +-----------------+--------------------------------------+
    | admin_state_up  | UP                                   |
    | created_at      | 2016-10-20T02:05:17Z                 |
    | description     |                                      |
    | id              | 0e4263e2-5761-4cf6-ab6d-b22884a0fa88 |
    | name            | parent-trunk                         |
    | port_id         | 20b6fdf8-0d43-475a-a0f1-ec8f757a4a39 |
    | revision_number | 1                                    |
    | status          | DOWN                                 |
    | sub_ports       |                                      |
    | tenant_id       | 745d33000ac74d30a77539f8920555e7     |
    | updated_at      | 2016-10-20T02:05:17Z                 |
    +-----------------+--------------------------------------+
  4. 트렁크 연결을 확인합니다.

    openstack network trunk list
    +--------------------------------------+--------------+--------------------------------------+-------------+
    | ID                                   | Name         | Parent Port                          | Description |
    +--------------------------------------+--------------+--------------------------------------+-------------+
    | 0e4263e2-5761-4cf6-ab6d-b22884a0fa88 | parent-trunk | 20b6fdf8-0d43-475a-a0f1-ec8f757a4a39 |             |
    +--------------------------------------+--------------+--------------------------------------+-------------+
  5. 트렁크 연결의 세부 정보를 확인합니다.

    openstack network trunk show parent-trunk
    +-----------------+--------------------------------------+
    | Field           | Value                                |
    +-----------------+--------------------------------------+
    | admin_state_up  | UP                                   |
    | created_at      | 2016-10-20T02:05:17Z                 |
    | description     |                                      |
    | id              | 0e4263e2-5761-4cf6-ab6d-b22884a0fa88 |
    | name            | parent-trunk                         |
    | port_id         | 20b6fdf8-0d43-475a-a0f1-ec8f757a4a39 |
    | revision_number | 1                                    |
    | status          | DOWN                                 |
    | sub_ports       |                                      |
    | tenant_id       | 745d33000ac74d30a77539f8920555e7     |
    | updated_at      | 2016-10-20T02:05:17Z                 |
    +-----------------+--------------------------------------+

11.5. 트렁크에 하위 포트 추가

  1. neutron 포트를 생성합니다.

    이 포트는 트렁크에 대한 하위 포트 연결입니다. 부모 포트에 할당한 MAC 주소도 지정해야 합니다.

    openstack port create --network private --mac-address fa:16:3e:33:c4:75 subport-trunk-port
    +-----------------------+--------------------------------------------------------------------------+
    | Field                 | Value                                                                    |
    +-----------------------+--------------------------------------------------------------------------+
    | admin_state_up        | UP                                                                       |
    | allowed_address_pairs |                                                                          |
    | binding_host_id       |                                                                          |
    | binding_profile       |                                                                          |
    | binding_vif_details   |                                                                          |
    | binding_vif_type      | unbound                                                                  |
    | binding_vnic_type     | normal                                                                   |
    | created_at            | 2016-10-20T02:08:14Z                                                     |
    | description           |                                                                          |
    | device_id             |                                                                          |
    | device_owner          |                                                                          |
    | extra_dhcp_opts       |                                                                          |
    | fixed_ips             | ip_address='10.0.0.11', subnet_id='1a299780-56df-4c0b-a4c0-c5a612cef2e8' |
    | headers               |                                                                          |
    | id                    | 479d742e-dd00-4c24-8dd6-b7297fab3ee9                                     |
    | mac_address           | fa:16:3e:33:c4:75                                                        |
    | name                  | subport-trunk-port                                                       |
    | network_id            | 3fe6b758-8613-4b17-901e-9ba30a7c4b51                                     |
    | project_id            | 745d33000ac74d30a77539f8920555e7                                         |
    | project_id            | 745d33000ac74d30a77539f8920555e7                                         |
    | revision_number       | 4                                                                        |
    | security_groups       | 59e2af18-93c6-4201-861b-19a8a8b79b23                                     |
    | status                | DOWN                                                                     |
    | updated_at            | 2016-10-20T02:08:15Z                                                     |
    +-----------------------+--------------------------------------------------------------------------+
    참고

    HttpException 오류가 발생하는 경우: conflict 는 상위 트렁크 포트가 있는 것과 다른 네트워크에서 하위 포트를 생성하고 있는지 확인합니다. 이 예에서는 상위 트렁크 포트에 공용 네트워크를 사용하고 하위 포트에 private을 사용합니다.

  2. 포트를 트렁크(parent-trunk)와 연결하고 VLAN ID(55)를 지정합니다.

    openstack network trunk set --subport port=subport-trunk-port,segmentation-type=vlan,segmentation-id=55 parent-trunk

11.6. 트렁크를 사용하도록 인스턴스 구성

하위 포트에 할당된 RHOSP(Red Hat OpenStack Platform) 네트워킹 서비스(neutron)의 MAC 주소를 사용하도록 VM 인스턴스 운영 체제를 구성해야 합니다. 하위 포트 생성 단계에서 특정 MAC 주소를 사용하도록 하위 포트를 구성할 수도 있습니다.

사전 요구 사항

  • 컴퓨팅 노드의 실시간 마이그레이션을 수행하는 경우 RHOSP 네트워킹 서비스 RPC 응답 타임아웃이 RHOSP 배포에 적절하게 설정되어 있는지 확인합니다. RPC 응답 시간 초과 값은 사이트마다 다를 수 있으며 시스템 속도에 따라 달라집니다. 일반적인 권장 사항은 값을 트렁크 포트당 120초 이상으로 설정하는 것입니다.

    RHOSP 배포의 트렁크 포트 바인딩 프로세스를 측정한 다음 RHOSP Networking 서비스 RPC 응답 타임아웃을 적절하게 설정하는 것이 좋습니다. RPC 응답 시간 초과 값을 낮게 유지하려고 하지만 RHOSP 네트워킹 서비스에서 RPC 응답을 받을 수 있는 충분한 시간도 제공합니다. 자세한 내용은 11.7절. “네트워킹 서비스 RPC 타임아웃 구성”의 내용을 참조하십시오.

절차

  1. 네트워크 트렁크 명령을 사용하여 네트워크 트렁크의 구성을 검토합니다.

    예제

    $ openstack network trunk list

    샘플 출력

    +---------------------+--------------+---------------------+-------------+
    | ID                  | Name         | Parent Port         | Description |
    +---------------------+--------------+---------------------+-------------+
    | 0e4263e2-5761-4cf6- | parent-trunk | 20b6fdf8-0d43-475a- |             |
    | ab6d-b22884a0fa88   |              | a0f1-ec8f757a4a39   |             |
    +---------------------+--------------+---------------------+-------------+

    예제

    $ openstack network trunk show parent-trunk

    샘플 출력

    +-----------------+------------------------------------------------------+
    | Field           | Value                                                |
    +-----------------+------------------------------------------------------+
    | admin_state_up  | UP                                                   |
    | created_at      | 2021-10-20T02:05:17Z                                 |
    | description     |                                                      |
    | id              | 0e4263e2-5761-4cf6-ab6d-b22884a0fa88                 |
    | name            | parent-trunk                                         |
    | port_id         | 20b6fdf8-0d43-475a-a0f1-ec8f757a4a39                 |
    | revision_number | 2                                                    |
    | status          | DOWN                                                 |
    | sub_ports       | port_id='479d742e-dd00-4c24-8dd6-b7297fab3ee9', segm |
    |                 | entation_id='55', segmentation_type='vlan'           |
    | tenant_id       | 745d33000ac74d30a77539f8920555e7                     |
    | updated_at      | 2021-08-20T02:10:06Z                                 |
    +-----------------+------------------------------------------------------+

  2. 상위 port-id 를 vNIC로 사용하는 인스턴스를 생성합니다.

    예제

    openstack server create --image cirros --flavor m1.tiny --security-group default --key-name sshaccess --nic port-id=20b6fdf8-0d43-475a-a0f1-ec8f757a4a39 testInstance

    샘플 출력

    +--------------------------------------+---------------------------------+
    | Property                             | Value                           |
    +--------------------------------------+---------------------------------+
    | OS-DCF:diskConfig                    | MANUAL                          |
    | OS-EXT-AZ:availability_zone          |                                 |
    | OS-EXT-SRV-ATTR:host                 | -                               |
    | OS-EXT-SRV-ATTR:hostname             | testinstance                    |
    | OS-EXT-SRV-ATTR:hypervisor_hostname  | -                               |
    | OS-EXT-SRV-ATTR:instance_name        |                                 |
    | OS-EXT-SRV-ATTR:kernel_id            |                                 |
    | OS-EXT-SRV-ATTR:launch_index         | 0                               |
    | OS-EXT-SRV-ATTR:ramdisk_id           |                                 |
    | OS-EXT-SRV-ATTR:reservation_id       | r-juqco0el                      |
    | OS-EXT-SRV-ATTR:root_device_name     | -                               |
    | OS-EXT-SRV-ATTR:user_data            | -                               |
    | OS-EXT-STS:power_state               | 0                               |
    | OS-EXT-STS:task_state                | scheduling                      |
    | OS-EXT-STS:vm_state                  | building                        |
    | OS-SRV-USG:launched_at               | -                               |
    | OS-SRV-USG:terminated_at             | -                               |
    | accessIPv4                           |                                 |
    | accessIPv6                           |                                 |
    | adminPass                            | uMyL8PnZRBwQ                    |
    | config_drive                         |                                 |
    | created                              | 2021-08-20T03:02:51Z            |
    | description                          | -                               |
    | flavor                               | m1.tiny (1)                     |
    | hostId                               |                                 |
    | host_status                          |                                 |
    | id                                   | 88b7aede-1305-4d91-a180-67e7eac |
    |                                      | 8b70d                           |
    | image                                | cirros (568372f7-15df-4e61-a05f |
    |                                      | -10954f79a3c4)                  |
    | key_name                             | sshaccess                       |
    | locked                               | False                           |
    | metadata                             | {}                              |
    | name                                 | testInstance                    |
    | os-extended-volumes:volumes_attached | []                              |
    | progress                             | 0                               |
    | security_groups                      | default                         |
    | status                               | BUILD                           |
    | tags                                 | []                              |
    | tenant_id                            | 745d33000ac74d30a77539f8920555e |
    |                                      | 7                               |
    | updated                              | 2021-08-20T03:02:51Z            |
    | user_id                              | 8c4aea738d774967b4ef388eb41fef5 |
    |                                      | e                               |
    +--------------------------------------+---------------------------------+

11.7. 네트워킹 서비스 RPC 타임아웃 구성

RHOSP(Red Hat OpenStack Platform) Networking 서비스(neutron) RPC 응답 타임아웃을 수정해야 하는 경우가 있을 수 있습니다. 예를 들어 시간 초과 값이 너무 작으면 트렁크 포트를 사용하는 컴퓨팅 노드의 실시간 마이그레이션이 실패할 수 있습니다.

RPC 응답 시간 초과 값은 사이트마다 다를 수 있으며 시스템 속도에 따라 달라집니다. 일반적인 권장 사항은 값을 트렁크 포트당 120초 이상으로 설정하는 것입니다.

사이트에서 트렁크 포트를 사용하는 경우 가장 좋은 방법은 RHOSP 배포의 트렁크 포트 바인딩 프로세스 시간을 측정한 다음 RHOSP Networking 서비스 RPC 응답 타임아웃을 적절하게 설정하는 것입니다. RPC 응답 시간 초과 값을 낮게 유지하려고 하지만 RHOSP 네트워킹 서비스에서 RPC 응답을 받을 수 있는 충분한 시간도 제공합니다.

수동 hieradata 덮어쓰기 rpc_response_timeout 을 사용하면 RHOSP 네트워킹 서비스의 RPC 응답 시간 초과 값을 설정할 수 있습니다.

절차

  1. 언더클라우드 호스트에서 stack 사용자로 로그인한 사용자 지정 YAML 환경 파일을 생성합니다.

    예제

    $ vi /home/stack/templates/my-modules-environment.yaml

    작은 정보

    RHOSP Orchestration 서비스(heat)에서는 템플릿 이라는 플랜 세트를 사용하여 환경을 설치하고 구성합니다. 사용자 지정 환경 파일을 사용하여 오버클라우드의 특정 부분을 사용자 지정할 수 있습니다. 이 파일은 heat 템플릿에 대한 사용자 지정 사용자 지정을 제공하는 특수한 유형의 템플릿입니다.

  2. ExtraConfig 의 YAML 환경 파일에서 rpc_response_timeout 에 적절한 값(초)을 설정합니다. (기본값은 60초입니다.)

    예제

    parameter_defaults:
      ExtraConfig:
        neutron::rpc_response_timeout: 120

    참고

    RHOSP Orchestration 서비스(heat)는 사용자 정의 환경 파일에 설정한 값으로 모든 RHOSP 노드를 업데이트하지만 이 값은 RHOSP 네트워킹 구성 요소에만 영향을 미칩니다.

  3. openstack overcloud deploy 명령을 실행하고 코어 heat 템플릿, 환경 파일 및 이 새 사용자 지정 환경 파일을 포함합니다.

    중요

    후속 환경 파일에 정의된 매개변수 및 리소스가 우선하므로 환경 파일의 순서가 중요합니다.

    예제

    $ openstack overcloud deploy --templates \
    -e [your-environment-files] \
    -e /usr/share/openstack-tripleo-heat-templates/environments/services/my-modules-environment.yaml

추가 리소스

11.8. 트렁크 상태 이해

  • 활성: 트렁크는 예상대로 작동하고 현재 요청이 없습니다.
  • DOWN: 트렁크의 가상 및 물리적 리소스가 동기화되지 않습니다. 이는 협상 중에 일시적인 상태일 수 있습니다.
  • BUILD: 요청이 있고 리소스가 프로비저닝되고 있습니다. 성공적으로 완료되면 트렁크는 EgressIP로 돌아갑니다.
  • 성능 저하: 프로비저닝 요청이 완료되지 않았으므로 트렁크는 부분적으로만 프로비저닝되었습니다. 하위 포트를 제거하고 다시 시도하는 것이 좋습니다.
  • ERROR: 배포 요청에 실패했습니다. 오류가 발생한 리소스를 제거하여 트렁크를 더 안전한 상태로 반환합니다. ERROR 상태인 동안 하위 포트를 추가하지 마십시오. 이로 인해 더 많은 문제가 발생할 수 있습니다.

12장. RBAC 정책 구성

12.1. RBAC 정책 개요

OpenStack 네트워킹의 RBAC(역할 기반 액세스 제어) 정책을 통해 공유 neutron 네트워크를 세부적으로 제어할 수 있습니다. OpenStack Networking에서는 RBAC 테이블을 사용하여 프로젝트 간 neutron 네트워크 공유를 제어하여 관리자가 인스턴스를 네트워크에 연결할 수 있는 권한이 부여된 프로젝트를 제어할 수 있습니다.

결과적으로 클라우드 관리자는 일부 프로젝트에서 네트워크를 생성할 수 있는 기능을 제거할 수 있으며 대신 해당 프로젝트에 해당하는 기존 네트워크에 연결할 수 있습니다.

12.2. RBAC 정책 생성

다음 예제 절차에서는 RBAC(역할 기반 액세스 제어) 정책을 사용하여 공유 네트워크에 대한 프로젝트 액세스 권한을 부여하는 방법을 보여줍니다.

  1. 사용 가능한 네트워크 목록을 확인합니다.

    # openstack network list
    +--------------------------------------+-------------+-------------------------------------------------------+
    | id                                   | name        | subnets                                               |
    +--------------------------------------+-------------+-------------------------------------------------------+
    | fa9bb72f-b81a-4572-9c7f-7237e5fcabd3 | web-servers | 20512ffe-ad56-4bb4-b064-2cb18fecc923 192.168.200.0/24 |
    | bcc16b34-e33e-445b-9fde-dd491817a48a | private     | 7fe4a05a-4b81-4a59-8c47-82c965b0e050 10.0.0.0/24      |
    | 9b2f4feb-fee8-43da-bb99-032e4aaf3f85 | public      | 2318dc3b-cff0-43fc-9489-7d4cf48aaab9 172.24.4.224/28  |
    +--------------------------------------+-------------+-------------------------------------------------------+
  2. 프로젝트 목록을 확인합니다.

    # openstack project list
    +----------------------------------+----------+
    | ID                               | Name     |
    +----------------------------------+----------+
    | 4b0b98f8c6c040f38ba4f7146e8680f5 | auditors |
    | 519e6344f82e4c079c8e2eabb690023b | services |
    | 80bf5732752a41128e612fe615c886c6 | demo     |
    | 98a2f53c20ce4d50a40dac4a38016c69 | admin    |
    +----------------------------------+----------+
  3. 감사 자 프로젝트(4b0b98f8c6c040f7146e8680f5)에 대한 액세스를 부여하는 서버에 대한 RBAC 항목을 만듭니다.

    # openstack network rbac create --type network --target-project 4b0b98f8c6c040f38ba4f7146e8680f5 --action access_as_shared web-servers
    Created a new rbac_policy:
    +----------------+--------------------------------------+
    | Field          | Value                                |
    +----------------+--------------------------------------+
    | action         | access_as_shared                     |
    | id             | 314004d0-2261-4d5e-bda7-0181fcf40709 |
    | object_id      | fa9bb72f-b81a-4572-9c7f-7237e5fcabd3 |
    | object_type    | network                              |
    | target_project | 4b0b98f8c6c040f38ba4f7146e8680f5     |
    | project_id     | 98a2f53c20ce4d50a40dac4a38016c69     |
    +----------------+--------------------------------------+

그 결과 감사 자 프로젝트의 사용자는 인스턴스를 web-servers 네트워크에 연결할 수 있습니다.

12.3. RBAC 정책 검토

  1. openstack network rbac list 명령을 실행하여 기존 역할 기반 액세스 제어(RBAC) 정책의 ID를 검색합니다.

    # openstack network rbac list
    +--------------------------------------+-------------+--------------------------------------+
    | id                                   | object_type | object_id                            |
    +--------------------------------------+-------------+--------------------------------------+
    | 314004d0-2261-4d5e-bda7-0181fcf40709 | network     | fa9bb72f-b81a-4572-9c7f-7237e5fcabd3 |
    | bbab1cf9-edc5-47f9-aee3-a413bd582c0a | network     | 9b2f4feb-fee8-43da-bb99-032e4aaf3f85 |
    +--------------------------------------+-------------+--------------------------------------+
  2. openstack network rbac-show 명령을 실행하여 특정 RBAC 항목의 세부 정보를 확인합니다.

    # openstack network rbac show 314004d0-2261-4d5e-bda7-0181fcf40709
    +----------------+--------------------------------------+
    | Field          | Value                                |
    +----------------+--------------------------------------+
    | action         | access_as_shared                     |
    | id             | 314004d0-2261-4d5e-bda7-0181fcf40709 |
    | object_id      | fa9bb72f-b81a-4572-9c7f-7237e5fcabd3 |
    | object_type    | network                              |
    | target_project | 4b0b98f8c6c040f38ba4f7146e8680f5     |
    | project_id     | 98a2f53c20ce4d50a40dac4a38016c69     |
    +----------------+--------------------------------------+

12.4. RBAC 정책 삭제

  1. openstack network rbac list 명령을 실행하여 기존 역할 기반 액세스 제어(RBAC) 정책의 ID를 검색합니다.

    # openstack network rbac list
    +--------------------------------------+-------------+--------------------------------------+
    | id                                   | object_type | object_id                            |
    +--------------------------------------+-------------+--------------------------------------+
    | 314004d0-2261-4d5e-bda7-0181fcf40709 | network     | fa9bb72f-b81a-4572-9c7f-7237e5fcabd3 |
    | bbab1cf9-edc5-47f9-aee3-a413bd582c0a | network     | 9b2f4feb-fee8-43da-bb99-032e4aaf3f85 |
    +--------------------------------------+-------------+--------------------------------------+
  2. 삭제하려는 RBAC의 ID를 사용하여 openstack network rbac delete 명령을 실행하여 RBAC를 삭제합니다.

    # openstack network rbac delete 314004d0-2261-4d5e-bda7-0181fcf40709
    Deleted rbac_policy: 314004d0-2261-4d5e-bda7-0181fcf40709

12.5. 외부 네트워크에 대한 RBAC 정책 액세스 권한 부여

--action access_as_external 매개변수를 사용하여 외부 네트워크( 게이트웨이 인터페이스가 연결된 네트워크)에 대한 역할 기반 액세스 제어(RBAC) 정책 액세스 권한을 부여할 수 있습니다.

web-servers 네트워크에 대한 RBAC를 생성하고 엔지니어링 프로젝트(c717f263785d4679b16a122516247deb)에 대한 액세스 권한을 부여하려면 다음 예제 프로시저의 단계를 완료합니다.

  • --action access_as_external 옵션을 사용하여 새 RBAC 정책을 생성합니다.

    # openstack network rbac create --type network --target-project c717f263785d4679b16a122516247deb --action access_as_external web-servers
     Created a new rbac_policy:
    +----------------+--------------------------------------+
    | Field          | Value                                |
    +----------------+--------------------------------------+
    | action         | access_as_external                   |
    | id             | ddef112a-c092-4ac1-8914-c714a3d3ba08 |
    | object_id      | 6e437ff0-d20f-4483-b627-c3749399bdca |
    | object_type    | network                              |
    | target_project | c717f263785d4679b16a122516247deb     |
    | project_id     | c717f263785d4679b16a122516247deb     |
    +----------------+--------------------------------------+

    결과적으로 엔지니어링 프로젝트의 사용자는 네트워크를 보거나 인스턴스를 연결할 수 있습니다.

    $ openstack network list
    +--------------------------------------+-------------+------------------------------------------------------+
    | id                                   | name        | subnets                                              |
    +--------------------------------------+-------------+------------------------------------------------------+
    | 6e437ff0-d20f-4483-b627-c3749399bdca | web-servers | fa273245-1eff-4830-b40c-57eaeac9b904 192.168.10.0/24 |
    +--------------------------------------+-------------+------------------------------------------------------+

13장. DVR(분산 가상 라우팅) 구성

13.1. 분산 가상 라우팅(DVR) 이해

Red Hat OpenStack Platform을 배포할 때 중앙 집중식 라우팅 모델 또는 DVR 중에서 선택할 수 있습니다.

각 모델에는 장단점이 있습니다. 이 문서를 사용하여 중앙 집중식 라우팅 또는 DVR이 요구 사항에 더 적합한지 여부를 신중하게 계획하십시오.

새로운 기본 RHOSP 배포는 Open Virtual Network 메커니즘 드라이버(ML2/OVN)를 사용하여 DVR과 Modular Layer 2 플러그인을 사용합니다.

DVR은 ML2/OVS 배포에서 기본적으로 비활성화되어 있습니다.

13.1.1. 계층 3 라우팅 개요

Red Hat OpenStack Platform Networking 서비스(neutron)는 프로젝트 네트워크에 라우팅 서비스를 제공합니다. 라우터가 없으면 프로젝트 네트워크의 VM 인스턴스가 공유 L2 브로드캐스트 도메인을 통해 다른 인스턴스와 통신할 수 있습니다. 라우터를 생성하고 프로젝트 네트워크에 할당하면 해당 네트워크의 인스턴스에서 다른 프로젝트 네트워크 또는 업스트림과 통신할 수 있습니다(라우터에 외부 게이트웨이가 정의된 경우).

13.1.2. 라우팅 흐름

RHOSP(Red Hat OpenStack Platform)의 라우팅 서비스는 다음 세 가지 주요 흐름으로 분류할 수 있습니다.

  • east-West 라우팅 - 동일한 프로젝트의 여러 네트워크 간 트래픽 라우팅. 이 트래픽은 RHOSP 배포를 종료하지 않습니다. 이 정의는 IPv4 및 IPv6 서브넷에 모두 적용됩니다.
  • 유동 IP를 사용한 North-South 라우팅 - 유동 IP 주소 지정은 수정할 수 있고 VM 인스턴스 간 유동 IP 주소 변환(NAT)입니다. 유동 IP는 유동 IP와 네트워킹 서비스(neutron) 포트 간의 일대일 연결로 모델링되지만 NAT 변환을 수행하는 네트워킹 서비스 라우터와 연결하여 구현됩니다. 유동 IP 자체는 라우터에 외부 연결을 제공하는 uplink 네트워크에서 가져옵니다. 결과적으로 인스턴스는 외부 리소스(예: 인터넷의 끝점) 또는 기타 방법과 통신할 수 있습니다. 유동 IP는 IPv4 개념이며 IPv6에는 적용되지 않습니다. 프로젝트에서 사용하는 IPv6 주소 지정에서는 프로젝트 간에 겹치지 않은 GUA(Global Unicast Addresses)를 사용하므로 NAT 없이 라우팅할 수 있습니다.
  • 유동 IP( SNAT라고도 함) 없이 North-South 라우팅 - 네트워킹 서비스는 유동 IP가 할당되지 않은 인스턴스에 대해 기본 포트 주소 변환(PAT) 서비스를 제공합니다. 이 서비스를 사용하면 인스턴스에서 라우터를 통해 외부 엔드포인트와 통신할 수 있지만 다른 방법은 사용할 수 없습니다. 예를 들어 인스턴스에서는 인터넷에서 웹 사이트를 검색할 수 있지만 외부 웹 브라우저는 인스턴스 내에서 호스팅되는 웹 사이트를 탐색할 수 없습니다. SNAT는 IPv4 트래픽에만 적용됩니다. 또한 GUAs 접두사가 할당된 네트워킹 서비스 네트워크에서는 네트워킹 서비스 라우터 외부 게이트웨이 포트에서 외부 게이트웨이 포트에 NAT가 필요하지 않습니다.

13.1.3. 중앙 집중식 라우팅

원래 네트워킹 서비스(neutron)는 중성자 L3 에이전트가 관리하는 프로젝트의 가상 라우터가 모두 전용 노드 또는 노드 클러스터에 배포된 중앙 집중식 라우팅 모델로 설계되었습니다(네트워크 노드 또는 컨트롤러 노드로 참조). 즉, 라우팅 기능이 필요할 때마다(east/west, 유동 IP 또는 SNAT) 트래픽이 토폴로지의 전용 노드를 통과합니다. 이로 인해 여러 문제가 발생하고 하위 트래픽 흐름이 발생했습니다. 예를 들면 다음과 같습니다.

  • L3을 사용하여 두 인스턴스가 서로 통신해야 하는 경우, 인스턴스 간 트래픽은 컨트롤러 노드에 도달해야 합니다. 인스턴스가 동일한 컴퓨팅 노드에 예약되지만 트래픽은 여전히 컴퓨팅 노드를 떠나 컨트롤러로 이동하고 컴퓨팅 노드로 다시 라우팅해야 합니다. 이는 성능에 부정적인 영향을 미칩니다.
  • 유동 IP가 있는 인스턴스는 컨트롤러 노드를 통해 패킷을 수신 및 전송합니다. 즉, 외부 네트워크 게이트웨이 인터페이스는 컨트롤러 노드에서만 사용할 수 있으므로 트래픽이 인스턴스에서 시작되는지 또는 외부 네트워크에서 인스턴스를 대상으로 하는지, 컨트롤러 노드를 통과해야 합니다. 결과적으로 대규모 환경에서는 컨트롤러 노드의 트래픽이 과도하게 로드됩니다. 이는 성능 및 확장성에 영향을 미치며 외부 네트워크 게이트웨이 인터페이스에서 충분한 대역폭을 수용하도록 신중하게 계획해야 합니다. SNAT 트래픽에도 동일한 요구 사항이 적용됩니다.

L3 에이전트를 보다 효과적으로 확장하기 위해 Networking 서비스에서 L3 HA 기능을 사용하여 가상 라우터를 여러 노드에 배포할 수 있습니다. 컨트롤러 노드가 손실된 경우 HA 라우터는 다른 노드의 대기 시간으로 장애 조치되고 HA 라우터 장애 조치가 완료될 때까지 패킷이 손실됩니다.

13.2. DVR 개요

DVR(Distributed Virtual Routing)은 대체 라우팅 설계를 제공합니다. DVR은 컨트롤러 노드의 장애 도메인을 분리하고 L3 에이전트를 배포하고 모든 Compute 노드에 라우터를 예약하여 네트워크 트래픽을 최적화합니다. DVR에는 다음과 같은 특징이 있습니다.

  • east-West 트래픽은 분산된 방식으로 컴퓨팅 노드에서 직접 라우팅됩니다.
  • 유동 IP를 사용하는 North-South 트래픽이 컴퓨팅 노드에 분산 및 라우팅됩니다. 이를 위해 모든 컴퓨팅 노드에 외부 네트워크를 연결해야 합니다.
  • 유동 IP가 없는 North-South 트래픽은 배포되지 않으며 여전히 전용 컨트롤러 노드가 필요합니다.
  • 컨트롤러 노드의 L3 에이전트는 dvr_snat 모드를 사용하므로 노드가 SNAT 트래픽만 제공합니다.
  • neutron 메타데이터 에이전트는 모든 컴퓨팅 노드에 배포 및 배포됩니다. 메타데이터 프록시 서비스는 모든 분산 라우터에서 호스팅됩니다.

13.3. DVR의 알려진 문제 및 경고

  • DVR은 ML2 코어 플러그인 및 OVS(Open vSwitch) 메커니즘 드라이버 또는 ML2/OVN 메커니즘 드라이버로 제한됩니다. 다른 백엔드는 지원되지 않습니다.
  • ML2/OVS DVR 배포에서 Red Hat OpenStack Platform 로드 밸런싱 서비스(octavia)의 네트워크 트래픽은 컴퓨팅 노드 대신 컨트롤러 및 네트워크 노드를 거칩니다.
  • ML2/OVS 메커니즘 드라이버 네트워크 백엔드 및 DVR을 사용하면 VIP를 생성할 수 있습니다. 그러나 allowed_address_cidrs를 사용하여 바인딩된 포트에 할당된 IP 주소는 가상 포트 IP 주소(/32)와 일치해야 합니다.

    대신 바인딩된 포트에 CIDR 형식 IP 주소를 사용하는 경우 포트 전달은 백엔드에 구성되지 않으며 바인딩된 IP 포트에 도달하는 데 필요한 CIDR의 모든 IP에 대한 트래픽이 실패합니다.

  • DVR이 활성화된 경우에도 SNAT(네트워크 주소 변환) 트래픽이 배포되지 않습니다. SNAT는 작동하지만 모든 수신/egress 트래픽은 중앙 집중식 컨트롤러 노드를 통해 이동해야 합니다.
  • ML2/OVS 배포에서 DVR이 활성화된 경우에도 IPv6 트래픽이 배포되지 않습니다. 모든 수신/egress 트래픽은 중앙 집중식 컨트롤러 노드를 통해 이루어집니다. ML2/OVS와 함께 IPv6 라우팅을 광범위하게 사용하는 경우 DVR을 사용하지 마십시오.

    ML2/OVN 배포에서 모든 east/west 트래픽이 항상 분산되며 DVR이 구성된 경우 north/south 트래픽이 분산됩니다.

  • ML2/OVS 배포에서 DVR은 L3 HA와 함께 지원되지 않습니다. Red Hat OpenStack Platform 17.0 director와 함께 DVR을 사용하는 경우 L3 HA가 비활성화됩니다. 즉, 네트워크 노드(및 L3 에이전트 간에 로드 공유)에 여전히 라우터를 예약하지만, 한 에이전트가 실패하면 이 에이전트에서 호스팅하는 모든 라우터도 실패합니다. 이는 SNAT 트래픽에만 영향을 미칩니다. 이러한 경우 allow_automatic_l3agent_failover 기능이 권장되므로 네트워크 노드가 실패하면 라우터가 다른 노드로 다시 예약됩니다.
  • neutron DHCP 에이전트에서 관리하는 DHCP 서버는 배포되지 않으며 여전히 컨트롤러 노드에 배포됩니다. DHCP 에이전트는 라우팅 설계(중앙화 또는 DVR)에 관계없이 컨트롤러 노드의 고가용성 구성에 배포됩니다.
  • 컴퓨팅 노드에는 외부 브리지에 연결된 외부 네트워크의 인터페이스가 필요합니다. 이 인터페이스를 사용하여 외부 라우터 게이트웨이의 VLAN 또는 플랫 네트워크에 연결하고, 유동 IP를 호스팅하고, 유동 IP를 사용하는 VM에 SNAT를 수행합니다.
  • ML2/OVS 배포에서 각 컴퓨팅 노드에는 하나의 추가 IP 주소가 필요합니다. 이는 외부 게이트웨이 포트 및 유동 IP 네트워크 네임스페이스의 구현 때문입니다.
  • VLAN, GRE, VXLAN은 모두 프로젝트 데이터 분리에 지원됩니다. GRE 또는 VXLAN을 사용하는 경우 L2 Population 기능을 활성화해야 합니다. Red Hat OpenStack Platform director는 설치 중에 L2 Population를 시행합니다.

13.4. 지원되는 라우팅 아키텍처

RHOSP(Red Hat OpenStack Platform)는 나열된 RHOSP 버전에서 중앙 집중식 HA(고가용성) 라우팅 및 DVR(분산 가상 라우팅)을 모두 지원합니다.

  • RHOSP 8에서 RHOSP 중앙 집중식 HA 라우팅 지원이 시작되었습니다.
  • RHOSP 12에서 RHOSP 분산 라우팅 지원이 시작되었습니다.

13.5. 분산 라우팅으로 중앙 집중식 라우터 마이그레이션

이 섹션에서는 L3 HA 중앙 라우팅을 사용하는 Red Hat OpenStack Platform 배포의 분산 라우팅으로 업그레이드하는 방법을 설명합니다.

절차

  1. 배포를 업그레이드하고 제대로 작동하는지 확인합니다.
  2. director 스택 업데이트를 실행하여 DVR을 구성합니다.
  3. 기존 라우터를 통해 라우팅 기능이 올바르게 작동하는지 확인합니다.
  4. L3 HA 라우터를 직접 분산 하도록 전환할 수 없습니다. 대신 라우터마다 L3 HA 옵션을 비활성화한 다음 분산 옵션을 활성화합니다.
  1. 라우터를 비활성화합니다.

    예제

    $ openstack router set --disable router1

  2. 명확한 고가용성:

    예제

    $ openstack router set --no-ha router1

  3. DVR을 사용하도록 라우터를 구성합니다.

    예제

    $ openstack router set --distributed router1

  4. 라우터를 활성화합니다.

    예제

    $ openstack router set --enable router1

  5. 분산 라우팅이 올바르게 작동하는지 확인합니다.

13.6. DVR(Distributed Virtual Routing)이 비활성화된 ML2/OVN OpenStack 배포

RHOSP(Red Hat OpenStack Platform) 배포는 기본적으로 ML2/OVN(Open Virtual Network 메커니즘 드라이버) 및 DVR을 사용하여 neutron Modular Layer 2 플러그인으로 설정됩니다.

DVR 토폴로지에서 유동 IP 주소가 있는 컴퓨팅 노드는 가상 머신 인스턴스와 외부 연결(north-south 트래픽)을 제공하는 네트워크 간에 트래픽을 라우팅합니다. 인스턴스 간 트래픽(east-west 트래픽)도 배포됩니다.

선택적으로 DVR이 비활성화된 상태로 배포할 수 있습니다. 이를 통해 north-south DVR이 비활성화되므로 컨트롤러 또는 네트워크 노드를 통과하는 데 north-south 트래픽이 필요합니다. East-west 라우팅은 DVR이 비활성화된 경우에도 ML2/OVN 배포로 항상 배포됩니다.

사전 요구 사항

  • RHOSP 17.0 배포는 사용자 지정 및 배포에 사용할 수 있습니다.

절차

  1. 사용자 지정 환경 파일을 생성하고 다음 구성을 추가합니다.

    parameter_defaults:
      NeutronEnableDVR: false
  2. 이 구성을 적용하려면 오버클라우드를 배포하고 사용자 지정 환경 파일을 스택에 다른 환경 파일과 함께 추가합니다. 예를 들면 다음과 같습니다.

    (undercloud) $ openstack overcloud deploy --templates \
      -e [your environment files]
      -e /home/stack/templates/<custom-environment-file>.yaml

13.6.1. 추가 리소스

14장. IPv6을 사용한 프로젝트 네트워킹

14.1. IPv6 서브넷 옵션

RHOSP(Red Hat OpenStack Platform) 프로젝트 네트워크에서 IPv6 서브넷을 생성할 때 주소 모드 및 라우터 알림 모드를 지정하여 다음 표에 설명된 대로 특정 결과를 얻을 수 있습니다.

참고

RHOSP는 ML2/OVN 배포의 IPv6 접두사 위임을 지원하지 않습니다. 글로벌 Unicast Address 접두사를 수동으로 설정해야 합니다.

RA 모드주소 모드결과

ipv6_ra_mode=not set

ipv6-address-mode=slaac

인스턴스는 외부 라우터(OpenStack 네트워킹에서 관리하지 않음)에서 SLAAC(상태 비저장 주소 자동 구성)를 사용하여 IPv6 주소를 수신합니다.

참고

OpenStack Networking은 RuntimeClass에 대한 EUI-64 IPv6 주소 할당만 지원합니다. 이를 통해 기본 64비트와 MAC 주소를 기반으로 호스트가 자체 할당 주소로 IPv6 네트워킹을 간소화할 수 있습니다. 다른 넷마스크와 address_assign_type 의 subnet을 생성할 수 없습니다.

ipv6_ra_mode=not set

ipv6-address-mode=dhcpv6-stateful

인스턴스는 DHCPv6 stateful 을 사용하여 OpenStack Networking(dnsmasq)에서 IPv6 주소 및 선택적 정보를 수신합니다.

ipv6_ra_mode=not set

ipv6-address-mode=dhcpv6-stateless

인스턴스는 sysfs를 사용하여 외부 라우터에서 IPv6 주소를 수신하며 DHCPv6 상태 비저장 을 사용하여 OpenStack Networking(dnsmasq)에서 선택적 정보를 받습니다.

ipv6_ra_mode=slaac

ipv6-address-mode=not-set

인스턴스에서 sysfs를 사용하여 OpenStack Networking(radvd)에서 IPv6 주소를 수신합니다.

ipv6_ra_mode=dhcpv6-stateful

ipv6-address-mode=not-set

인스턴스는 DHCPv6 stateful 을 사용하여 외부 DHCPv6 서버에서 IPv6 주소 및 선택적 정보를 수신합니다.

ipv6_ra_mode=dhcpv6-stateless

ipv6-address-mode=not-set

인스턴스는 RuntimeClass를 사용하여 OpenStack Networking(radvd)에서 IPv6 주소를 수신하고 DHCPv6 stateless 를 사용하여 외부 DHCPv6 서버에서 선택적 정보를 수신합니다.

ipv6_ra_mode=slaac

ipv6-address-mode=slaac

인스턴스는 RHEA를 사용하여 OpenStack Networking(radvd)에서 IPv6 주소를 수신합니다.

ipv6_ra_mode=dhcpv6-stateful

ipv6-address-mode=dhcpv6-stateful

인스턴스는 DHCPv6 stateful 을 사용하여 OpenStack Networking(dnsmasq)에서 IPv6 주소를 수신하고 DHCPv6 stateful 을 사용하여dnsmasq(OpenStack Networking)에서 선택적 정보를 수신합니다.

ipv6_ra_mode=dhcpv6-stateless

ipv6-address-mode=dhcpv6-stateless

인스턴스는 RuntimeClass를 사용하여 OpenStack Networking(radvd)에서 IPv6 주소를 수신하며 DHCPv6 상태 비저장 을 사용하여 OpenStack Networking(dnsmasq)에서 선택적 정보를 수신합니다.

14.2. Stateful DHCPv6을 사용하여 IPv6 서브넷 만들기

RHOSP(Red Hat OpenStack) 프로젝트 네트워크에서 IPv6 서브넷을 생성할 수 있습니다.

예를 들어 successfully라는 프로젝트의 database-servers 네트워크에서 Stateful DHCPv6을 사용하여 IPv6 서브넷을 생성할 수 있습니다.

절차

  1. IPv6 서브넷을 만들 프로젝트의 프로젝트 ID를 검색합니다. 이러한 값은 OpenStack 배포 간에 고유하므로 값은 이 예의 값과 다릅니다.

    # openstack project list
    +----------------------------------+----------+
    | ID                               | Name     |
    +----------------------------------+----------+
    | 25837c567ed5458fbb441d39862e1399 |    QA    |
    | f59f631a77264a8eb0defc898cb836af |  admin   |
    | 4e2e1951e70643b5af7ed52f3ff36539 |   demo   |
    | 8561dff8310e4cd8be4b6fd03dc8acf5 | services |
    +----------------------------------+----------+
  2. OpenStack Networking(neutron)에 있는 모든 네트워크 목록을 검색하고 IPv6 서브넷을 호스팅할 네트워크의 이름을 확인합니다.

    # openstack network list
    +--------------------------------------+------------------+-------------------------------------------------------------+
    | id                                   | name             | subnets                                                     |
    +--------------------------------------+------------------+-------------------------------------------------------------+
    | 8357062a-0dc2-4146-8a7f-d2575165e363 | private          | c17f74c4-db41-4538-af40-48670069af70 10.0.0.0/24            |
    | 31d61f7d-287e-4ada-ac29-ed7017a54542 | public           | 303ced03-6019-4e79-a21c-1942a460b920 172.24.4.224/28        |
    | 6aff6826-4278-4a35-b74d-b0ca0cbba340 | database-servers |                                                             |
    +--------------------------------------+------------------+-------------------------------------------------------------+
  3. openstack subnet create 명령에 프로젝트 ID, 네트워크 이름 및 ipv6 주소 모드를 포함합니다.

    # openstack subnet create --ip-version 6 --ipv6-address-mode dhcpv6-stateful --project 25837c567ed5458fbb441d39862e1399 --network database-servers --subnet-range fdf8:f53b:82e4::53/125 subnet_name
    
    Created a new subnet:
    +-------------------+--------------------------------------------------------------+
    | Field             | Value                                                        |
    +-------------------+--------------------------------------------------------------+
    | allocation_pools  | {"start": "fdf8:f53b:82e4::52", "end": "fdf8:f53b:82e4::56"} |
    | cidr              | fdf8:f53b:82e4::53/125                                       |
    | dns_nameservers   |                                                              |
    | enable_dhcp       | True                                                         |
    | gateway_ip        | fdf8:f53b:82e4::51                                           |
    | host_routes       |                                                              |
    | id                | cdfc3398-997b-46eb-9db1-ebbd88f7de05                         |
    | ip_version        | 6                                                            |
    | ipv6_address_mode | dhcpv6-stateful                                              |
    | ipv6_ra_mode      |                                                              |
    | name              |                                                              |
    | network_id        | 6aff6826-4278-4a35-b74d-b0ca0cbba340                         |
    | tenant_id         | 25837c567ed5458fbb441d39862e1399                             |
    +-------------------+--------------------------------------------------------------+

검증 단계

  1. 네트워크 목록을 검토하여 이 구성을 검증합니다. database-servers 에 대한 항목은 이제 새로 생성된 IPv6 서브넷을 반영합니다.

    # openstack network list
    +--------------------------------------+------------------+-------------------------------------------------------------+
    | id                                   | name             | subnets                                                     |
    +--------------------------------------+------------------+-------------------------------------------------------------+
    | 6aff6826-4278-4a35-b74d-b0ca0cbba340 | database-servers | cdfc3398-997b-46eb-9db1-ebbd88f7de05 fdf8:f53b:82e4::50/125 |
    | 8357062a-0dc2-4146-8a7f-d2575165e363 | private          | c17f74c4-db41-4538-af40-48670069af70 10.0.0.0/24            |
    | 31d61f7d-287e-4ada-ac29-ed7017a54542 | public           | 303ced03-6019-4e79-a21c-1942a460b920 172.24.4.224/28        |
    +--------------------------------------+------------------+-------------------------------------------------------------+

    결과

    이 구성의 결과로 database-servers 서브넷에 추가될 때 stderr 프로젝트가 생성하는 인스턴스는 DHCP IPv6 주소를 수신할 수 있습니다.

    # openstack server list
    +--------------------------------------+------------+--------+------------+-------------+-------------------------------------+
    | ID                                   | Name       | Status | Task State | Power State | Networks                            |
    +--------------------------------------+------------+--------+------------+-------------+-------------------------------------+
    | fad04b7a-75b5-4f96-aed9-b40654b56e03 | corp-vm-01 | ACTIVE | -          | Running     | database-servers=fdf8:f53b:82e4::52 |
    +--------------------------------------+------------+--------+------------+-------------+-------------------------------------+

추가 리소스

IPv6 서브넷에서 특정 결과를 달성하기 위한 라우터 알림 모드 및 주소 모드 조합을 찾으려면 네트워킹 가이드의 IPv6 서브넷 옵션을 참조하십시오.

15장. 프로젝트 할당량 관리

15.1. 프로젝트 할당량 구성

OpenStack Networking(neutron)은 할당량을 사용하여 테넌트/프로젝트에서 생성한 리소스 수를 제한할 수 있습니다.

절차

  • /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf 파일에서 다양한 네트워크 구성 요소의 프로젝트 할당량을 설정할 수 있습니다.

    예를 들어 프로젝트에서 생성할 수 있는 라우터 수를 제한하려면 quota_router 값을 변경합니다.

    quota_router = 10

    이 예에서 각 프로젝트는 최대 10개의 라우터로 제한됩니다.

할당량 설정 목록은 즉시 따르는 섹션을 참조하십시오.

15.2. L3 할당량 옵션

계층 3(L3) 네트워킹에 사용할 수 있는 할당량 옵션은 다음과 같습니다.

  • quota_floatingip - 프로젝트에서 사용할 수 있는 유동 IP 수입니다.
  • quota_network - 프로젝트에서 사용할 수 있는 네트워크 수입니다.
  • quota_port - 프로젝트에 사용 가능한 포트 수입니다.
  • quota_router - 프로젝트에서 사용할 수 있는 라우터 수입니다.
  • quota_subnet - 프로젝트에 사용 가능한 서브넷 수입니다.
  • quota_vip - 프로젝트에서 사용할 수 있는 가상 IP 주소 수입니다.

15.3. 방화벽 할당량 옵션

다음은 프로젝트의 방화벽을 관리하는 데 사용할 수 있는 할당량 옵션입니다.

  • quota_firewall - 프로젝트에 사용할 수 있는 방화벽 수입니다.
  • quota_firewall_policy - 프로젝트에 사용 가능한 방화벽 정책 수입니다.
  • quota_firewall_rule - 프로젝트에 사용할 수 있는 방화벽 규칙 수입니다.

15.4. 보안 그룹 할당량 옵션

네트워킹 서비스 할당량 엔진은 보안 그룹 및 보안 그룹 규칙을 관리하며 기본 보안 그룹을 생성하기 전에 모든 할당량을 0으로 설정할 수 없습니다(및 IPv4 및 IPv6의 모든 송신 트래픽을 허용하는 두 개의 기본 보안 그룹 규칙). 새 프로젝트를 생성할 때 Networking 서비스는 네트워크 또는 포트가 생성될 때까지 또는 보안 그룹 또는 보안 그룹 규칙을 나열할 때까지 기본 보안 그룹을 생성하지 않습니다.

다음은 프로젝트에서 생성할 수 있는 보안 그룹 수를 관리하는 데 사용할 수 있는 할당량 옵션입니다.

  • quota_security_group - 프로젝트에서 사용할 수 있는 보안 그룹 수입니다.
  • quota_security_group_rule - 프로젝트에서 사용할 수 있는 보안 그룹 규칙 수입니다.

15.5. 관리 할당량 옵션

다음은 관리자가 프로젝트 할당량을 관리하는 데 사용할 수 있는 추가 옵션은 다음과 같습니다.

  • default_quota* - 프로젝트에서 사용할 수 있는 기본 리소스 수입니다.
  • quota_health_monitor* 프로젝트에서 사용할 수 있는 상태 모니터 수입니다.

    상태 모니터는 리소스를 사용하지 않지만 OpenStack Networking에서 상태 모니터를 리소스 소비자로 간주하므로 할당량 옵션을 사용할 수 있습니다.

  • quota_member - 프로젝트에서 사용할 수 있는 풀 멤버 수입니다.

    풀 멤버는 리소스를 사용하지 않지만 OpenStack Networking에서 풀 멤버를 리소스 소비자로 간주하므로 할당량 옵션을 사용할 수 있습니다.

  • quota_pool - 프로젝트에서 사용할 수 있는 풀 수입니다.

16장. 라우팅된 공급자 네트워크 배포

16.1. 라우팅된 공급자 네트워크의 이점

RHOSP(Red Hat OpenStack Platform)에서 Operator는 라우팅된 공급자 네트워크를 생성할 수 있습니다. 라우팅된 공급자 네트워크는 일반적으로 에지 배포에서 사용되며, 하나의 세그먼트만 있는 기존 네트워크 대신 여러 계층 2 네트워크 세그먼트에 의존합니다.

라우팅된 공급자 네트워크는 하나의 네트워크만 보기 때문에 최종 사용자를 위한 클라우드를 단순화합니다. 클라우드 운영자의 경우 라우팅된 공급자 네트워크는 스칼라빌리티 및 내결함성을 제공합니다. 예를 들어 주요 오류가 발생하면 전체 네트워크가 실패하는 대신 하나의 세그먼트만 영향을 받습니다.

공급자 네트워크를 라우팅하기 전에 Operator는 일반적으로 다음 아키텍처 중 하나를 선택해야 했습니다.

  • 하나의 대규모 계층 2 네트워크
  • 다중, 더 작은 계층 2 네트워크

단일 계층 2 네트워크는 확장 및 내결함성(실패 도메인)을 줄일 때 대규모 계층 2 네트워크가 복잡해집니다.

여러 개의 작은 계층 2 네트워크는 더 나은 확장 및 장애 도메인을 축소하지만 최종 사용자에게 복잡성을 유발할 수 있습니다.

RHOSP 16.2 이상부터는 Open Virtual Network 메커니즘 드라이버(ML2/OVN)와 함께 Modular Layer 2 플러그인을 사용하여 라우팅된 공급자 네트워크를 배포할 수 있습니다. ( ML2/Open vSwitch(OVS) 및 SR-IOV 메커니즘 드라이버에 대한 라우팅된 공급자 네트워크 지원이 RHOSP 16.1.1에서 도입되었습니다.

16.2. 라우팅된 공급자 네트워크의 기본 사항

네트워크 서브넷과 세그먼트 간의 일대일 연결 때문에 라우팅된 공급자 네트워크는 다른 유형의 네트워크와 다릅니다. 이전에는 모든 서브넷이 동일한 세그먼트에 속하거나 세그먼트를 사용하지 않아야 하기 때문에 RHOSP(Red Hat OpenStack) 네트워킹 서비스는 라우팅 공급자 네트워크를 지원하지 않았습니다.

라우팅된 공급자 네트워크를 사용하면 VM(가상 머신) 인스턴스에서 사용할 수 있는 IP 주소는 특정 컴퓨팅 노드에서 사용 가능한 네트워크의 세그먼트에 따라 달라집니다. 네트워킹 서비스 포트는 하나의 네트워크 세그먼트와만 연결할 수 있습니다.

기존 네트워킹과 유사하게 계층 2(스케팅)는 동일한 네트워크 세그먼트에서 포트 간 트래픽 전송을 처리하고 3 계층(라우팅)은 세그먼트 간 트래픽 전송을 처리합니다.

네트워킹 서비스는 세그먼트 간에 계층 3 서비스를 제공하지 않습니다. 대신, 서브넷을 라우팅하기 위해 물리적 네트워크 인프라에 의존합니다. 따라서 네트워킹 서비스와 물리적 네트워크 인프라 모두 기존 공급자 네트워크와 유사하게 라우팅된 공급자 네트워크에 대한 구성을 포함해야 합니다.

Compute 서비스(nova) 스케줄러는 네트워크 세그먼트를 인식하지 않으므로 라우팅 공급자 네트워크를 배포할 때 각 리프 또는 랙 세그먼트 또는 DCN 에지 사이트를 Compute 서비스 호스트 집계 또는 가용 영역에 매핑해야 합니다.

DHCP-metadata 서비스가 필요한 경우 로컬 DHCP 에이전트가 배포되도록 각 에지 사이트 또는 네트워크 세그먼트에 대한 가용성 영역을 정의해야 합니다.

16.3. 라우팅된 공급자 네트워크의 제한 사항

라우팅된 공급자 네트워크는 모든 메커니즘 드라이버에서 지원하지 않으며 다음 목록에 언급된 Compute 서비스 스케줄러 및 기타 소프트웨어에 대한 제한이 있습니다.

  • 중앙 SNAT 또는 유동 IP를 사용한 North-south 라우팅은 지원되지 않습니다.
  • SR-IOV 또는 PCI 패스스루를 사용하는 경우 물리적 네트워크(physnet) 이름은 중앙 및 원격 사이트나 세그먼트에서 동일해야 합니다. 세그먼트 ID를 재사용할 수 없습니다.
  • Compute 서비스(nova) 스케줄러는 세그먼트를 인식하지 않습니다. (각 세그먼트 또는 에지 사이트를 Compute 호스트 집계 또는 가용 영역에 매핑해야 합니다.) 현재는 두 개의 VM 인스턴스 부팅 옵션만 사용할 수 있습니다.

    • port-id 및 IP 주소 없음을 사용하여 부팅하여 Compute 가용성 영역(세그먼트 또는 에지 사이트)을 지정합니다.
    • network-id 를 사용하여 부팅하여 Compute 가용성 영역(세그먼트 또는 에지 사이트)을 지정합니다.
  • 콜드 또는 실시간 마이그레이션은 대상 Compute 가용 영역(세그먼트 또는 에지 사이트)을 지정하는 경우에만 작동합니다.

16.4. 라우팅 공급자 네트워크 준비

RHOSP(Red Hat OpenStack Platform)에서 라우팅된 공급자 네트워크를 생성하기 전에 수행해야 하는 여러 작업이 있습니다.

절차

  1. 네트워크 내에서 각 세그먼트에 고유한 물리적 네트워크 이름을 사용합니다. 이렇게 하면 서브넷 간에 동일한 분할 세부 정보를 재사용할 수 있습니다.

    예를 들어 특정 공급자 네트워크의 모든 세그먼트에서 동일한 VLAN ID를 사용합니다.

  2. 세그먼트 간 라우팅을 구현합니다.

    세그먼트의 각 서브넷에는 해당 특정 서브넷에 있는 라우터 인터페이스의 게이트웨이 주소가 포함되어야 합니다.

    표 16.1. 라우팅을 위한 샘플 세그먼트

    segment버전주소게이트웨이

    segment1

    4

    203.0.113.0/24

    203.0.113.1

    segment1

    6

    fd00:203:0:113::/64

    fd00:203:0:113::1

    segment2

    4

    198.51.100.0/24

    198.51.100.1

    segment2

    6

    fd00:198:51:100::/64

    fd00:198:51:100::1

  3. Compute 노드에 세그먼트를 매핑합니다.

    라우팅된 공급자 네트워크는 컴퓨팅 노드가 다른 세그먼트에 있음을 나타냅니다. 라우팅된 공급자 네트워크의 모든 Compute 호스트가 해당 세그먼트 중 하나에 직접 연결되어 있는지 확인합니다.

    표 16.2. 컴퓨팅 노드 매핑에 대한 샘플 세그먼트

    hostRack물리적 네트워크

    compute0001

    Rack 1

    세그먼트 1

    compute0002

    Rack 1

    세그먼트 1

    compute0101

    Rack 2

    세그먼트 2

    compute0102

    Rack 2

    세그먼트 2

    compute0102

    Rack 2

    세그먼트 2

  4. Open vSwitch 메커니즘 드라이버(ML2/OVS)를 사용하여 Modular Layer 2 플러그인을 사용하여 배포하는 경우 세그먼트당 하나 이상의 DHCP 에이전트를 배포해야 합니다.

    기존 공급자 네트워크와 달리 DHCP 에이전트는 네트워크 내에서 두 개 이상의 세그먼트를 지원할 수 없습니다. 노드 수를 줄이기 위해 네트워크 노드가 아닌 세그먼트가 포함된 컴퓨팅 노드에 DHCP 에이전트를 배포합니다.

    표 16.3. 세그먼트 매핑당 샘플 DHCP 에이전트

    hostRack물리적 네트워크

    network0001

    Rack 1

    세그먼트 1

    network0002

    Rack 1

    세그먼트 1

    사용자 지정 역할 파일을 사용하여 컴퓨팅 노드에 DHCP 에이전트 및 RHOSP Networking 서비스(neutron) 메타데이터 에이전트를 배포합니다.

    예를 들면 다음과 같습니다.

    ###############################################################################
    # Role: ComputeSriov                                                          #
    ###############################################################################
    - name: ComputeSriov
      description: |
        Compute SR-IOV Role
      CountDefault: 1
      networks:
        External:
          subnet: external_subnet
        InternalApi:
          subnet: internal_api_subnet
        Tenant:
          subnet: tenant_subnet
        Storage:
          subnet: storage_subnet
      RoleParametersDefault:
        TunedProfileName: "cpu-partitioning"
      update_serial: 25
      ServicesDefault:
        - OS::TripleO::Services::Aide
        - OS::TripleO::Services::AuditD
        - OS::TripleO::Services::BootParams
        - OS::TripleO::Services::CACerts
    ...
        - OS::TripleO::Services::NeutronDhcpAgent
        - OS::TripleO::Services::NeutronMetadataAgent
    ...

    사용자 지정 환경 파일에서 다음 키-값 쌍을 추가합니다.

    parameter_defaults:
        ....
        NeutronEnableIsolatedMetadata: 'True'
        ....

16.5. 라우팅된 공급자 네트워크 생성

라우팅된 공급자 네트워크는 하나의 네트워크만 표시하므로 최종 사용자를 위한 RHOSP(Red Hat OpenStack Platform) 클라우드를 단순화합니다. 클라우드 운영자의 경우 라우팅된 공급자 네트워크는 스칼라빌리티 및 내결함성을 제공합니다.

이 절차를 수행하면 두 개의 네트워크 세그먼트가 있는 라우팅된 공급자 네트워크를 생성합니다. 각 세그먼트에는 하나의 IPv4 서브넷과 하나의 IPv6 서브넷이 있습니다.

사전 요구 사항

  • xref:prepare-routed-prov-network_deploy-routed-prov-networks에서 단계를 완료합니다.

절차

  1. 기본 세그먼트가 포함된 VLAN 공급자 네트워크를 생성합니다.

    이 예에서 VLAN 공급자 네트워크의 이름은 multisegment1 이고, provider1 이라는 물리적 네트워크와 ID가 128 인 VLAN을 사용합니다.

    예제

    $ openstack network create --share --provider-physical-network provider1 \
      --provider-network-type vlan --provider-segment 128 multisegment1

    샘플 출력

    +---------------------------+--------------------------------------+
    | Field                     | Value                                |
    +---------------------------+--------------------------------------+
    | admin_state_up            | UP                                   |
    | id                        | 6ab19caa-dda9-4b3d-abc4-5b8f435b98d9 |
    | ipv4_address_scope        | None                                 |
    | ipv6_address_scope        | None                                 |
    | l2_adjacency              | True                                 |
    | mtu                       | 1500                                 |
    | name                      | multisegment1                        |
    | port_security_enabled     | True                                 |
    | provider:network_type     | vlan                                 |
    | provider:physical_network | provider1                            |
    | provider:segmentation_id  | 128                                  |
    | revision_number           | 1                                    |
    | router:external           | Internal                             |
    | shared                    | True                                 |
    | status                    | ACTIVE                               |
    | subnets                   |                                      |
    | tags                      | []                                   |
    +---------------------------+--------------------------------------+

  2. 기본 네트워크 세그먼트의 이름을 segment1 로 변경합니다.

    1. 세그먼트 ID를 가져옵니다.

      $ openstack network segment list --network multisegment1

      샘플 출력

      +--------------------------------------+----------+--------------------------------------+--------------+---------+
      | ID                                   | Name     | Network                              | Network Type | Segment |
      +--------------------------------------+----------+--------------------------------------+--------------+---------+
      | 43e16869-ad31-48e4-87ce-acf756709e18 | None     | 6ab19caa-dda9-4b3d-abc4-5b8f435b98d9 | vlan         | 128     |
      +--------------------------------------+----------+--------------------------------------+--------------+---------+

    2. 세그먼트 ID를 사용하여 네트워크 세그먼트 이름을 segment1 로 변경합니다.

      $ openstack network segment set --name segment1 43e16869-ad31-48e4-87ce-acf756709e18
  3. 공급자 네트워크에 두 번째 세그먼트를 생성합니다.

    이 예에서 네트워크 세그먼트는 provider2 라는 물리적 네트워크와 ID가 129 인 VLAN을 사용합니다.

    예제

    $ openstack network segment create --physical-network provider2 \
      --network-type vlan --segment 129 --network multisegment1 segment2

    샘플 출력

    +------------------+--------------------------------------+
    | Field            | Value                                |
    +------------------+--------------------------------------+
    | description      | None                                 |
    | headers          |                                      |
    | id               | 053b7925-9a89-4489-9992-e164c8cc8763 |
    | name             | segment2                             |
    | network_id       | 6ab19caa-dda9-4b3d-abc4-5b8f435b98d9 |
    | network_type     | vlan                                 |
    | physical_network | provider2                            |
    | revision_number  | 1                                    |
    | segmentation_id  | 129                                  |
    | tags             | []                                   |
    +------------------+--------------------------------------+

  4. 네트워크에 segment1segment2 세그먼트가 포함되어 있는지 확인합니다.

    $ openstack network segment list --network multisegment1

    샘플 출력

    +--------------------------------------+----------+--------------------------------------+--------------+---------+
    | ID                                   | Name     | Network                              | Network Type | Segment |
    +--------------------------------------+----------+--------------------------------------+--------------+---------+
    | 053b7925-9a89-4489-9992-e164c8cc8763 | segment2 | 6ab19caa-dda9-4b3d-abc4-5b8f435b98d9 | vlan         | 129     |
    | 43e16869-ad31-48e4-87ce-acf756709e18 | segment1 | 6ab19caa-dda9-4b3d-abc4-5b8f435b98d9 | vlan         | 128     |
    +--------------------------------------+----------+--------------------------------------+--------------+---------+

  5. segment1 세그먼트에 하나의 IPv4 서브넷과 하나의 IPv6 서브넷을 만듭니다.

    이 예에서 IPv4 서브넷에서는 203.0.113.0/24 를 사용합니다.

    예제

    $ openstack subnet create \
      --network multisegment1 --network-segment segment1 \
      --ip-version 4 --subnet-range 203.0.113.0/24 \
      multisegment1-segment1-v4

    샘플 출력

    +-------------------+--------------------------------------+
    | Field             | Value                                |
    +-------------------+--------------------------------------+
    | allocation_pools  | 203.0.113.2-203.0.113.254            |
    | cidr              | 203.0.113.0/24                       |
    | enable_dhcp       | True                                 |
    | gateway_ip        | 203.0.113.1                          |
    | id                | c428797a-6f8e-4cb1-b394-c404318a2762 |
    | ip_version        | 4                                    |
    | name              | multisegment1-segment1-v4            |
    | network_id        | 6ab19caa-dda9-4b3d-abc4-5b8f435b98d9 |
    | revision_number   | 1                                    |
    | segment_id        | 43e16869-ad31-48e4-87ce-acf756709e18 |
    | tags              | []                                   |
    +-------------------+--------------------------------------+

    이 예에서 IPv6 서브넷은 fd00:203:0:113::/64 를 사용합니다.

    예제

    $ openstack subnet create \
      --network multisegment1 --network-segment segment1 \
      --ip-version 6 --subnet-range fd00:203:0:113::/64 \
      --ipv6-address-mode slaac multisegment1-segment1-v6

    샘플 출력

    +-------------------+------------------------------------------------------+
    | Field             | Value                                                |
    +-------------------+------------------------------------------------------+
    | allocation_pools  | fd00:203:0:113::2-fd00:203:0:113:ffff:ffff:ffff:ffff |
    | cidr              | fd00:203:0:113::/64                                  |
    | enable_dhcp       | True                                                 |
    | gateway_ip        | fd00:203:0:113::1                                    |
    | id                | e41cb069-9902-4c01-9e1c-268c8252256a                 |
    | ip_version        | 6                                                    |
    | ipv6_address_mode | slaac                                                |
    | ipv6_ra_mode      | None                                                 |
    | name              | multisegment1-segment1-v6                            |
    | network_id        | 6ab19caa-dda9-4b3d-abc4-5b8f435b98d9                 |
    | revision_number   | 1                                    |
    | segment_id        | 43e16869-ad31-48e4-87ce-acf756709e18                 |
    | tags              | []                                                   |
    +-------------------+------------------------------------------------------+

    참고

    기본적으로 공급자 네트워크의 IPv6 서브넷은 상태 비저장 주소 자동 구성(SLAAC) 및 라우터 알림을 위해 물리적 네트워크 인프라에 의존합니다.

  6. segment2 세그먼트에 하나의 IPv4 서브넷과 하나의 IPv6 서브넷을 만듭니다.

    이 예에서 IPv4 서브넷에서는 198.51.100.0/24 를 사용합니다.

    예제

    $ openstack subnet create \
      --network multisegment1 --network-segment segment2 \
      --ip-version 4 --subnet-range 198.51.100.0/24 \
      multisegment1-segment2-v4

    샘플 출력

    +-------------------+--------------------------------------+
    | Field             | Value                                |
    +-------------------+--------------------------------------+
    | allocation_pools  | 198.51.100.2-198.51.100.254          |
    | cidr              | 198.51.100.0/24                      |
    | enable_dhcp       | True                                 |
    | gateway_ip        | 198.51.100.1                         |
    | id                | 242755c2-f5fd-4e7d-bd7a-342ca95e50b2 |
    | ip_version        | 4                                    |
    | name              | multisegment1-segment2-v4            |
    | network_id        | 6ab19caa-dda9-4b3d-abc4-5b8f435b98d9 |
    | revision_number   | 1                                    |
    | segment_id        | 053b7925-9a89-4489-9992-e164c8cc8763 |
    | tags              | []                                   |
    +-------------------+--------------------------------------+

    이 예에서 IPv6 서브넷은 fd00:198:51:100::/64 를 사용합니다.

    예제

    $ openstack subnet create \
      --network multisegment1 --network-segment segment2 \
      --ip-version 6 --subnet-range fd00:198:51:100::/64 \
      --ipv6-address-mode slaac multisegment1-segment2-v6

    샘플 출력

    +-------------------+--------------------------------------------------------+
    | Field             | Value                                                  |
    +-------------------+--------------------------------------------------------+
    | allocation_pools  | fd00:198:51:100::2-fd00:198:51:100:ffff:ffff:ffff:ffff |
    | cidr              | fd00:198:51:100::/64                                   |
    | enable_dhcp       | True                                                   |
    | gateway_ip        | fd00:198:51:100::1                                     |
    | id                | b884c40e-9cfe-4d1b-a085-0a15488e9441                   |
    | ip_version        | 6                                                      |
    | ipv6_address_mode | slaac                                                  |
    | ipv6_ra_mode      | None                                                   |
    | name              | multisegment1-segment2-v6                              |
    | network_id        | 6ab19caa-dda9-4b3d-abc4-5b8f435b98d9                   |
    | revision_number   | 1                                                      |
    | segment_id        | 053b7925-9a89-4489-9992-e164c8cc8763                   |
    | tags              | []                                                     |
    +-------------------+--------------------------------------------------------+

검증

  1. 각 IPv4 서브넷이 하나 이상의 DHCP 에이전트와 연결되어 있는지 확인합니다.

    $ openstack network agent list --agent-type dhcp --network multisegment1

    샘플 출력

    +--------------------------------------+------------+-------------+-------------------+-------+-------+--------------------+
    | ID                                   | Agent Type | Host        | Availability Zone | Alive | State | Binary             |
    +--------------------------------------+------------+-------------+-------------------+-------+-------+--------------------+
    | c904ed10-922c-4c1a-84fd-d928abaf8f55 | DHCP agent | compute0001 | nova              | :-)   | UP    | neutron-dhcp-agent |
    | e0b22cc0-d2a6-4f1c-b17c-27558e20b454 | DHCP agent | compute0101 | nova              | :-)   | UP    | neutron-dhcp-agent |
    +--------------------------------------+------------+-------------+-------------------+-------+-------+--------------------+

  2. Compute 서비스 배치 API의 각 세그먼트 IPv4 서브넷에 대해 인벤토리가 생성되었는지 확인합니다.

    모든 세그먼트 ID에 대해 이 명령을 실행합니다.

    $ SEGMENT_ID=053b7925-9a89-4489-9992-e164c8cc8763
    $ openstack resource provider inventory list $SEGMENT_ID

    샘플 출력

    이 샘플 출력에서는 세그먼트 중 하나만 표시됩니다.

    +----------------+------------------+----------+----------+-----------+----------+-------+
    | resource_class | allocation_ratio | max_unit | reserved | step_size | min_unit | total |
    +----------------+------------------+----------+----------+-----------+----------+-------+
    | IPV4_ADDRESS   |              1.0 |        1 |        2 |         1 |        1 |    30 |
    +----------------+------------------+----------+----------+-----------+----------+-------+
  3. Compute 서비스의 각 세그먼트에 대해 호스트 집계가 생성되었는지 확인합니다.

    $ openstack aggregate list

    샘플 출력

    이 예제에서는 세그먼트 중 하나만 표시됩니다.

    +----+---------------------------------------------------------+-------------------+
    | Id | Name                                                    | Availability Zone |
    +----+---------------------------------------------------------+-------------------+
    | 10 | Neutron segment id 053b7925-9a89-4489-9992-e164c8cc8763 | None              |
    +----+---------------------------------------------------------+-------------------+
  4. 하나 이상의 인스턴스를 시작합니다. 각 인스턴스는 특정 계산 노드에서 사용하는 세그먼트에 따라 IP 주소를 가져옵니다.

    참고

    포트 생성 요청의 사용자가 고정 IP를 지정하면 해당 특정 IP가 포트에 즉시 할당됩니다. 그러나 포트를 생성하고 인스턴스에 전달하면 기존 네트워크와 다른 동작이 생성됩니다. 포트 생성 요청에 고정 IP를 지정하지 않으면 특정 계산 노드가 나타날 때까지 네트워킹 서비스에서 포트에 IP 주소 할당을 지연합니다. 예를 들어 다음 명령을 실행하는 경우:

    $ openstack port create --network multisegment1 port1

    샘플 출력

    +-----------------------+--------------------------------------+
    | Field                 | Value                                |
    +-----------------------+--------------------------------------+
    | admin_state_up        | UP                                   |
    | binding_vnic_type     | normal                               |
    | id                    | 6181fb47-7a74-4add-9b6b-f9837c1c90c4 |
    | ip_allocation         | deferred                             |
    | mac_address           | fa:16:3e:34:de:9b                    |
    | name                  | port1                                |
    | network_id            | 6ab19caa-dda9-4b3d-abc4-5b8f435b98d9 |
    | port_security_enabled | True                                 |
    | revision_number       | 1                                    |
    | security_groups       | e4fcef0d-e2c5-40c3-a385-9c33ac9289c5 |
    | status                | DOWN                                 |
    | tags                  | []                                   |
    +-----------------------+--------------------------------------+

추가 리소스

16.6. 라우팅되지 않은 네트워크를 라우팅된 공급자 네트워크로 마이그레이션

네트워크의 서브넷을 네트워크 세그먼트의 ID와 연결하여 라우팅되지 않은 네트워크를 라우팅 공급자 네트워크로 마이그레이션할 수 있습니다.

사전 요구 사항

  • 마이그레이션 중인 라우팅되지 않은 네트워크에는 하나의 세그먼트와 하나의 서브넷 포함되어야 합니다.

    중요

    여러 서브넷 또는 네트워크 세그먼트가 포함된 라우팅되지 않은 공급자 네트워크는 라우팅된 공급자 네트워크로 안전하게 마이그레이션할 수 없습니다. 라우팅되지 않은 네트워크에서 서브넷 할당 풀의 주소는 포트가 바인딩된 네트워크 세그먼트를 고려하지 않고 포트에 할당됩니다.

절차

  1. 마이그레이션 중인 네트워크의 경우 현재 네트워크 세그먼트의 ID를 가져옵니다.

    예제

    $ openstack network segment list --network my_network

    샘플 출력

    +--------------------------------------+------+--------------------------------------+--------------+---------+
    | ID                                   | Name | Network                              | Network Type | Segment |
    +--------------------------------------+------+--------------------------------------+--------------+---------+
    | 81e5453d-4c9f-43a5-8ddf-feaf3937e8c7 | None | 45e84575-2918-471c-95c0-018b961a2984 | flat         | None    |
    +--------------------------------------+------+--------------------------------------+--------------+---------+

  2. 마이그레이션 중인 네트워크의 경우 현재 서브넷의 ID를 가져옵니다.

    예제

    $ openstack network segment list --network my_network

    샘플 출력

    +--------------------------------------+-----------+--------------------------------------+---------------+
    | ID                                   | Name      | Network                              | Subnet        |
    +--------------------------------------+-----------+--------------------------------------+---------------+
    | 71d931d2-0328-46ae-93bc-126caf794307 | my_subnet | 45e84575-2918-471c-95c0-018b961a2984 | 172.24.4.0/24 |
    +--------------------------------------+-----------+--------------------------------------+---------------+

  3. 서브넷의 현재 segment_id 값이 None 인지 확인합니다.

    예제

    $ openstack subnet show my_subnet --c segment_id

    샘플 출력

    +------------+-------+
    | Field      | Value |
    +------------+-------+
    | segment_id | None  |
    +------------+-------+

  4. segment_id 서브넷의 값을 네트워크 세그먼트 ID로 변경합니다.

    예를 들면 다음과 같습니다.

    $ openstack subnet set --network-segment 81e5453d-4c9f-43a5-8ddf-feaf3937e8c7 my_subnet

검증

  • 서브넷이 이제 원하는 네트워크 세그먼트와 연결되어 있는지 확인합니다.

    예제

    $ openstack subnet show my_subnet --c segment_id

    샘플 출력

    +------------+--------------------------------------+
    | Field      | Value                                |
    +------------+--------------------------------------+
    | segment_id | 81e5453d-4c9f-43a5-8ddf-feaf3937e8c7 |
    +------------+--------------------------------------+

추가 리소스

17장. 허용되는 주소 쌍 구성

17.1. 허용되는 주소 쌍 개요

허용된 주소 쌍 은 특정 MAC 주소, IP 주소 또는 서브넷에 관계없이 네트워크 트래픽이 포트를 통과할 수 있도록 하는 경우입니다. 허용되는 주소 쌍을 정의할 때 빠른 데이터 플레인 페일오버를 활성화하기 위해 두 VM 인스턴스 간 IP 주소를 사용하는 VRRP(Virtual Router Redundancy Protocol)와 같은 프로토콜을 사용할 수 있습니다.

Red Hat OpenStack Platform 명령줄 클라이언트 openstack port 명령을 사용하여 허용되는 주소 쌍을 정의합니다.

중요

허용된 주소 쌍에서 더 광범위한 IP 주소 범위가 있는 기본 보안 그룹을 사용해서는 안 됩니다. 이렇게 하면 단일 포트가 동일한 네트워크 내의 다른 모든 포트에 대해 보안 그룹을 바이패스할 수 있습니다.

예를 들어 이 명령은 네트워크의 모든 포트에 영향을 미치고 모든 보안 그룹을 무시합니다.

# openstack port set --allowed-address mac-address=3e:37:09:4b,ip-address=0.0.0.0/0 9e67d44eab334f07bf82fa1b17d824b6
참고

ML2/OVN 메커니즘 드라이버 네트워크 백엔드를 사용하면 VIP를 생성할 수 있습니다. 그러나 allowed_address_cidrs를 사용하여 바인딩된 포트에 할당된 IP 주소는 가상 포트 IP 주소(/32)와 일치해야 합니다.

대신 바인딩된 포트에 CIDR 형식 IP 주소를 사용하는 경우 포트 전달은 백엔드에 구성되지 않으며 바인딩된 IP 포트에 도달하는 데 필요한 CIDR의 모든 IP에 대한 트래픽이 실패합니다.

17.2. 포트 생성 및 하나의 주소 쌍 허용

허용된 주소 쌍을 사용하여 포트를 생성하면 서브넷에 관계없이 포트 를 통해 네트워크 트래픽이 전달될 수 있습니다.

중요

허용된 주소 쌍에서 더 광범위한 IP 주소 범위에 있는 기본 보안 그룹을 사용하지 마십시오. 이렇게 하면 단일 포트가 동일한 네트워크 내의 다른 모든 포트에 대해 보안 그룹을 바이패스할 수 있습니다.

절차

  • 다음 명령을 사용하여 포트를 생성하고 하나의 주소 쌍을 허용합니다.

    $ openstack port create --network <network> --allowed-address mac-address=<mac_address>,ip-address=<ip_cidr> <port_name>

17.3. 허용된 주소 쌍 추가

서브넷에 관계없이 포트를 통해 네트워크 트래픽이 전달될 수 있도록 허용된 주소 쌍을 포트에 추가할 수 있습니다.

중요

허용된 주소 쌍에서 더 광범위한 IP 주소 범위에 있는 기본 보안 그룹을 사용하지 마십시오. 이렇게 하면 단일 포트가 동일한 네트워크 내의 다른 모든 포트에 대해 보안 그룹을 바이패스할 수 있습니다.

절차

  • 다음 명령을 사용하여 허용된 주소 쌍을 추가합니다.

    $ openstack port set --allowed-address mac-address=<mac_address>,ip-address=<ip_cidr> <port>
    참고

    포트의 mac_addressip_address 와 일치하는 allowed-address 쌍을 설정할 수 없습니다. 이는 mac_addressip_address 와 일치하는 트래픽이 이미 포트를 통과할 수 있기 때문에 이러한 설정이 적용되지 않기 때문입니다.

18장. 일반적인 관리 네트워킹 작업

계층 2 채우기 드라이버 구성 또는 내부 DNS에서 포트에 할당된 이름을 지정하는 등 Red Hat OpenStack Platform Networking 서비스(neutron)에서 관리 작업을 수행해야 하는 경우가 있습니다.

18.1. L2 채우기 드라이버 구성

L2 Population 드라이버를 사용하면 대규모 오버레이 네트워크에서 브로드캐스트, 멀티 캐스트 및 유니캐스트 트래픽을 확장할 수 있습니다. 기본적으로 Open vSwitch GRE 및 VXLAN은 대상 네트워크를 호스팅하지 않는 에이전트를 포함하여 모든 에이전트에 브로드캐스트를 복제합니다. 이 설계에는 상당한 네트워크 및 처리 오버헤드를 수락해야 합니다. L2 Population 드라이버에 의해 도입된 대체 설계는 ARP 해상도 및 MAC 학습 트래픽에 대한 부분 메시를 구현하며, 네트워크를 호스팅하는 노드 간에만 특정 네트워크에 대해 터널을 생성합니다. 이 트래픽은 대상 유니캐스트로 캡슐화하여 필요한 에이전트로만 전송됩니다.

L2 Population 드라이버를 활성화하려면 다음 단계를 완료합니다.

1. 메커니즘 드라이버 목록에 추가 하 여 L2 채우기 드라이버를 사용 하도록 설정 합니다. GRE, VXLAN 또는 둘 다의 터널링 드라이버를 하나 이상 활성화해야 합니다. ml2_conf.ini 파일에 적절한 구성 옵션을 추가합니다.

[ml2]
type_drivers = local,flat,vlan,gre,vxlan,geneve
mechanism_drivers = l2population
참고

Neutron의 Linux Bridge ML2 드라이버 및 에이전트는 Red Hat OpenStack Platform 11에서 더 이상 사용되지 않습니다. OVS(Open vSwitch) 플러그인 OpenStack Platform director는 기본적으로 Red Hat에서 일반적인 용도로 사용하는 것이 좋습니다.

2. openvswitch_agent.ini 파일에서 L2 채우기를 활성화합니다. L2 에이전트가 포함된 각 노드에서 활성화합니다.

[agent]
l2_population = True
참고

ARP 응답 흐름을 설치하려면 arp_responder 플래그를 구성합니다.

[agent]
l2_population = True
arp_responder = True

18.2. VRRP 패킷 손실을 방지하기 위해 keepalived 튜닝

단일 호스트의 HA(고가용성) 라우터 수가 높으면 HA 라우터가 장애 조치되면 VRRP(Virtual Router Redundancy Protocol) 메시지가 IRQ 큐를 오버플로할 수 있습니다. 이 오버플로는 OVS(Open vSwitch)가 해당 VRRP 메시지를 응답하고 전달하지 않습니다.

VRRP 패킷 과부하를 방지하려면 컨트롤러 역할의 ExtraConfig 섹션에서 ha_vrrp_advert_int 매개변수를 사용하여 VRRP 광고 간격을 늘려야 합니다.

절차

  1. stack 사용자로 언더클라우드에 로그인하고 stackrc 파일을 가져와 director 명령행 툴을 활성화합니다.

    예제

    $ source ~/stackrc

  2. 사용자 지정 YAML 환경 파일을 생성합니다.

    예제

    $ vi /home/stack/templates/my-neutron-environment.yaml

    작은 정보

    Red Hat OpenStack Platform Orchestration 서비스(heat)는 템플릿 이라는 일련의 계획을 사용하여 환경을 설치하고 구성합니다. 사용자 지정 환경 파일을 사용하여 오버클라우드의 특정 부분을 사용자 지정할 수 있습니다. 이 파일은 heat 템플릿에 대한 사용자 지정 사용자 지정을 제공하는 특수한 유형의 템플릿입니다.

  3. YAML 환경 파일에서 사이트에 고유한 값과 함께 ha_vrrp_advert_int 인수를 사용하여 VRRP 광고 간격을 늘립니다. (기본값은 2 초입니다.)

    불필요한 ARP 메시지의 값을 설정할 수도 있습니다.

    ha_vrrp_garp_master_repeat
    마스터 상태로 전환한 후 한 번에 전송할 불필요한 ARP 메시지 수입니다. (기본값은 5개입니다.)
    ha_vrrp_garp_master_delay

    우선순위가 낮은 advert가 마스터 상태에서 수신된 후의 보조 ARP 메시지 세트에 대한 지연입니다. (기본값은 5초입니다.)

    예제

    parameter_defaults:
      ControllerExtraConfig:
        neutron::agents::l3::ha_vrrp_advert_int: 7
        neutron::config::l3_agent_config:
          DEFAULT/ha_vrrp_garp_master_repeat:
            value: 5
          DEFAULT/ha_vrrp_garp_master_delay:
            value: 5

  4. openstack overcloud deploy 명령을 실행하고 코어 heat 템플릿, 환경 파일 및 이 새 사용자 지정 환경 파일을 포함합니다.

    중요

    후속 환경 파일에 정의된 매개 변수와 리소스가 우선하므로 환경 파일의 순서가 중요합니다.

    예제

    $ openstack overcloud deploy --templates \
    -e [your-environment-files] \
    -e /usr/share/openstack-tripleo-heat-templates/environments/services/my-neutron-environment.yaml

추가 리소스

18.3. DNS가 포트에 할당하는 이름 지정

포트 확장(dns_domain_ports)에 대해 RHOSP(Red Hat OpenStack Platform) Networking 서비스(neutron) dns_domain을 활성화하면 내부 DNS에서 포트에 할당된 이름을 지정할 수 있습니다.

YAML 형식의 환경 파일에서 RHOSP Orchestration(heat) NeutronPluginExtensions 매개변수를 선언하여 포트 확장을 위해 dns_domain을 활성화합니다. 해당 매개변수 NeutronDnsDomain 을 사용하여 도메인 이름을 지정하여 기본값 openstacklocal 을 덮어씁니다. 오버클라우드를 재배포한 후 OpenStack Client 포트 명령, 포트 세트 또는 포트 create--dns-name 과 함께 사용하여 포트 이름을 할당할 수 있습니다.

또한 포트 확장에 대한 dns_domain이 활성화되면 Compute 서비스에서 VM 인스턴스를 부팅하는 동안 인스턴스의 hostname 속성으로 dns_name 속성을 자동으로 채웁니다. 부팅 프로세스가 끝나면 dnsmasq는 인스턴스 호스트 이름으로 할당된 포트를 인식합니다.

절차

  1. stack 사용자로 언더클라우드에 로그인하고 stackrc 파일을 가져와 director 명령행 툴을 활성화합니다.

    예제

    $ source ~/stackrc

  2. 사용자 지정 YAML 환경 파일(my-neutron-environment.yaml)을 만듭니다.

    참고

    괄호 안에 있는 값은 다음 절차의 예제 명령에 사용되는 샘플 값입니다. 이러한 샘플 값을 사이트에 적합한 값으로 바꿉니다.

    예제

    $ vi /home/stack/templates/my-neutron-environment.yaml

    작은 정보

    언더클라우드에는 오버클라우드 생성 계획을 구성하는 오케스트레이션 서비스 템플릿 세트가 포함되어 있습니다. 코어 오케스트레이션 서비스 템플릿 컬렉션의 매개변수와 리소스를 재정의하는 YAML 형식의 파일인 환경 파일을 사용하여 오버클라우드의 특정 부분을 사용자 지정할 수 있습니다. 환경 파일은 필요한 수만큼 추가할 수 있습니다.

  3. 환경 파일에서 parameter_defaults 섹션을 추가합니다. 이 섹션에서는 포트 확장의 dns_domain_domains, dns_domain_ports 를 추가합니다.

    예제

    parameter_defaults:
      NeutronPluginExtensions: "qos,port_security,dns_domain_ports"

    참고

    dns_domain_ports 를 설정하는 경우 배포에서 DNS 통합 확장 기능인 dns_domain 도 사용하지 않는지 확인합니다. 이러한 확장은 호환되지 않으며 두 확장 모두 동시에 정의할 수 없습니다.

  4. 또한 parameter_defaults 섹션에서 NeutronDnsDomain 매개변수를 사용하여 도메인 이름(example.com)을 추가합니다.

    예제

    parameter_defaults:
        NeutronPluginExtensions: "qos,port_security,dns_domain_ports"
        NeutronDnsDomain: "example.com"

  5. openstack overcloud deploy 명령을 실행하고 코어 오케스트레이션 템플릿, 환경 파일 및 이 새 환경 파일을 포함합니다.

    중요

    후속 환경 파일에 정의된 매개 변수와 리소스가 우선하므로 환경 파일의 순서가 중요합니다.

    예제

    $ openstack overcloud deploy --templates \
    -e [your-environment-files] \
    -e /usr/share/openstack-tripleo-heat-templates/environments/services/my-neutron-environment.yaml

검증

  1. 오버클라우드에 로그인하고 네트워크(공용)에 새 포트(new_port)를 만듭니다. DNS 이름(my_port)을 포트에 할당합니다.

    예제

    $ source ~/overcloudrc
    $ openstack port create --network public --dns-name my_port new_port

  2. 포트(new_port)에 대한 세부 정보를 표시합니다.

    예제

    $ openstack port show -c dns_assignment -c dns_domain -c dns_name -c name new_port

    출력 결과

    +-------------------------+----------------------------------------------+
    | Field                   | Value                                        |
    +-------------------------+----------------------------------------------+
    | dns_assignment          | fqdn='my_port.example.com',                  |
    |                         | hostname='my_port',                          |
    |                         | ip_address='10.65.176.113'                   |
    | dns_domain              | example.com                                  |
    | dns_name                | my_port                                      |
    | name                    | new_port                                     |
    +-------------------------+----------------------------------------------+

    dns_assignment 에서 포트의 정규화된 도메인 이름(fqdn) 값에는 DNS 이름(my_port) 및 이전에 NeutronDnsDomain 으로 설정한 도메인 이름(example.com)의 연결이 포함되어 있습니다.

  3. 방금 생성한 포트(new_port)를 사용하여 새 VM 인스턴스(my_vm)를 생성합니다.

    예제

    $ openstack server create --image rhel --flavor m1.small --port new_port my_vm

  4. 포트(new_port)에 대한 세부 정보를 표시합니다.

    예제

    $ openstack port show -c dns_assignment -c dns_domain -c dns_name -c name new_port

    출력 결과

    +-------------------------+----------------------------------------------+
    | Field                   | Value                                        |
    +-------------------------+----------------------------------------------+
    | dns_assignment          | fqdn='my_vm.example.com',                    |
    |                         | hostname='my_vm',                            |
    |                         | ip_address='10.65.176.113'                   |
    | dns_domain              | example.com                                  |
    | dns_name                | my_vm                                        |
    | name                    | new_port                                     |
    +-------------------------+----------------------------------------------+

    Compute 서비스는 원래 값(my_port)의 dns_name 속성을 포트가 연결된 인스턴스의 이름으로 변경합니다(my_vm).

추가 리소스

18.4. 포트에 DHCP 속성 할당

RHOSP(Red Hat Openstack Plaform) 네트워킹 서비스(neutron) 확장을 사용하여 네트워킹 기능을 추가할 수 있습니다. 추가 DHCP 옵션 확장(extra_dhcp_opt)을 사용하여 DHCP 클라이언트의 포트를 DHCP 속성으로 구성할 수 있습니다. 예를 들어 tftp-server,server-ip-address, bootfile-name 과 같은 PXE 부팅 옵션을 DHCP 클라이언트 포트에 추가할 수 있습니다.

extra_dhcp_opt 속성 값은 DHCP 옵션 오브젝트의 배열이며, 각 오브젝트에는 opt_nameopt_value 가 포함됩니다. IPv4는 기본 버전이지만 세 번째 옵션 ip-version=6 을 포함하여 IPv6로 변경할 수 있습니다.

VM 인스턴스가 시작되면 RHOSP 네트워킹 서비스는 DHCP 프로토콜을 사용하여 인스턴스에 포트 정보를 제공합니다. 실행 중인 인스턴스에 이미 연결된 포트에 DHCP 정보를 추가하는 경우 인스턴스는 인스턴스를 다시 시작할 때만 새 DHCP 포트 정보를 사용합니다.

가장 일반적인 DHCP 포트 속성은 bootfile-name,dns-server,domain-name,mtu,server-ip-address, tftp-server 입니다. opt_name 에 허용되는 전체 값 세트는 DHCP 사양을 참조하십시오.

사전 요구 사항

  • RHOSP 관리자 권한이 있어야 합니다.

절차

  1. 언더클라우드 호스트에 stack 사용자로 로그인합니다.
  2. 언더클라우드 인증 정보 파일을 소싱합니다.

    $ source ~/stackrc
  3. 사용자 지정 YAML 환경 파일을 생성합니다.

    예제

    $ vi /home/stack/templates/my-octavia-environment.yaml

  4. 환경 파일에는 parameter_defaults 키워드가 포함되어야 합니다. 이러한 키워드 아래에 추가 DHCP 옵션 확장 기능 extra_dhcp_opt 를 추가합니다.

    예제

    parameter_defaults:
      NeutronPluginExtensions: "qos,port_security,extra_dhcp_opt"

  5. 배포 명령을 실행하고 코어 heat 템플릿, 환경 파일 및 이 새로운 사용자 지정 환경 파일을 포함합니다.

    중요

    후속 환경 파일에 정의된 매개 변수와 리소스가 우선하므로 환경 파일의 순서가 중요합니다.

    예제

    $ openstack overcloud deploy --templates \
    -e <your_environment_files> \
    -e /usr/share/openstack-tripleo-heat-templates/environments/services/octavia.yaml \
    -e /home/stack/templates/my-octavia-environment.yaml

검증

  1. 자격 증명 파일을 가져옵니다.

    예제

    $ source ~/overcloudrc

  2. 네트워크(공용)에서 새 포트(new_port)를 만듭니다. DHCP 사양의 유효한 속성을 새 포트에 할당합니다.

    예제

    $ openstack port create --extra-dhcp-option \
    name=domain-name,value=test.domain --extra-dhcp-option \
    name=ntp-server,value=192.0.2.123 --network public new_port

  3. 포트(new_port)에 대한 세부 정보를 표시합니다.

    예제

    $ openstack port show new_port -c extra_dhcp_opts

    샘플 출력

    +-----------------+-----------------------------------------------------------------+
    | Field           | Value                                                           |
    +-----------------+-----------------------------------------------------------------+
    | extra_dhcp_opts | ip_version='4', opt_name='domain-name', opt_value='test.domain' |
    |                 | ip_version='4', opt_name='ntp-server', opt_value='192.0.2.123'  |
    +-----------------+-----------------------------------------------------------------+

추가 리소스

18.5. 포트에서 NUMA 선호도 활성화

사용자가 포트에서 NUMA 선호도를 사용하여 인스턴스를 생성할 수 있도록 하려면 RHOSP(Red Hat Openstack Plaform) 네트워킹 서비스(neutron) 확장인 port_numa_affinity_policy 를 로드해야 합니다.

사전 요구 사항

  • 언더클라우드 호스트 및 stack 사용자의 자격 증명에 액세스합니다.

절차

  1. 언더클라우드 호스트에 stack 사용자로 로그인합니다.
  2. 언더클라우드 인증 정보 파일을 소싱합니다.

    $ source ~/stackrc
  3. port_numa_affinity_policy 확장을 활성화하려면 NeutronPluginExtensions 매개변수가 정의된 환경 파일을 열고 port_numa_affinity_policy 를 목록에 추가합니다.

    parameter_defaults:
      NeutronPluginExtensions: "qos,port_numa_affinity_policy"
  4. 다른 환경 파일을 사용하여 스택에 수정한 환경 파일을 추가하고 오버클라우드를 재배포합니다.

    중요

    후속 환경 파일에 정의된 매개 변수와 리소스가 우선하므로 환경 파일의 순서가 중요합니다.

    $ openstack overcloud deploy --templates \
    -e <your_environment_files> \
    -e /home/stack/templates/<custom_environment_file>.yaml

검증

  1. 자격 증명 파일을 가져옵니다.

    예제

    $ source ~/overcloudrc

  2. 새 포트를 생성합니다.

    포트를 생성할 때 다음 옵션 중 하나를 사용하여 NUMA 선호도 정책을 지정하여 포트에 적용합니다.

    • --NUMA-policy-required - 이 포트를 예약하는 데 필요한 NUMA 선호도 정책입니다.
    • --NUMA-policy-preferred - 이 포트를 예약하기 위해 기본 제공되는 NUMA 선호도 정책입니다.
    • --NUMA-policy-legacy - 레거시 모드를 사용하여 이 포트를 예약하는 NUMA 선호도 정책입니다.

      예제

      $ openstack port create --network public \
        --numa-policy-legacy  myNUMAAffinityPort

  3. 포트 세부 정보를 표시합니다.

    예제

    $ openstack port show myNUMAAffinityPort -c numa_affinity_policy

    샘플 출력

    확장 기능이 로드되면 Value 열, legacy,preferred 또는 required 가 표시되어야 합니다. 확장 기능을 로드하지 못한 경우 None 을 읽습니다.

    +----------------------+--------+
    | Field                | Value  |
    +----------------------+--------+
    | numa_affinity_policy | legacy |
    +----------------------+--------+

18.6. 커널 모듈 로드

RHOSP(Red Hat OpenStack Platform)의 일부 기능을 로드하려면 특정 커널 모듈을 로드해야 합니다. 예를 들어 OVS 방화벽 드라이버에서는 두 VM 인스턴스 간 GRE 터널링을 지원하기 위해 nf_conntrack_proto_gre 커널 모듈을 로드해야 합니다.

특수 Orchestration 서비스(heat) 매개변수인 ExtraKernelModules 를 사용하면 Heat에서 GRE 터널링과 같은 기능에 필요한 커널 모듈에 대한 구성 정보를 저장하도록 할 수 있습니다. 나중에 일반 모듈 관리 중에 이러한 필수 커널 모듈이 로드됩니다.

절차

  1. 언더클라우드 호스트에서 stack 사용자로 로그인한 사용자 지정 YAML 환경 파일을 생성합니다.

    예제

    $ vi /home/stack/templates/my-modules-environment.yaml

    작은 정보

    Heat는 템플릿 이라는 계획 집합을 사용하여 환경을 설치하고 구성합니다. 사용자 지정 환경 파일을 사용하여 오버클라우드의 특정 부분을 사용자 지정할 수 있습니다. 이 파일은 heat 템플릿에 대한 사용자 지정 사용자 지정을 제공하는 특수한 유형의 템플릿입니다.

  2. parameter_defaults 아래의 YAML 환경 파일에서 ExtraKernelModules 를 로드하려는 모듈 이름으로 설정합니다.

    예제

    ComputeParameters:
      ExtraKernelModules:
        nf_conntrack_proto_gre: {}
    ControllerParameters:
      ExtraKernelModules:
        nf_conntrack_proto_gre: {}

  3. openstack overcloud deploy 명령을 실행하고 코어 heat 템플릿, 환경 파일 및 이 새 사용자 지정 환경 파일을 포함합니다.

    중요

    후속 환경 파일에 정의된 매개변수 및 리소스가 우선하므로 환경 파일의 순서가 중요합니다.

    예제

    $ openstack overcloud deploy --templates \
    -e [your-environment-files] \
    -e /usr/share/openstack-tripleo-heat-templates/environments/services/my-modules-environment.yaml

검증

  • heat가 모듈을 올바르게 로드한 경우 컴퓨팅 노드에서 lsmod 명령을 실행할 때 출력이 표시됩니다.

    예제

    sudo lsmod | grep nf_conntrack_proto_gre

추가 리소스

18.7. 공유 보안 그룹 구성

RHOSP(Red Hat OpenStack Platform) 프로젝트에서 데이터를 공유할 수 있도록 하려면 RHOSP Networking 서비스(neutron) RBAC 정책 기능을 사용하여 보안 그룹을 공유할 수 있습니다. OpenStack Client를 사용하여 보안 그룹 및 네트워킹 서비스 역할 기반 액세스 제어(RBAC) 정책을 생성합니다.

인스턴스를 생성하는 동안 인스턴스에 직접 보안 그룹을 적용하거나 실행 중인 인스턴스의 포트에 적용할 수 있습니다.

참고

인스턴스를 생성하는 동안에는 RBAC(역할 기반 액세스 제어)-공유 보안 그룹을 인스턴스에 직접 적용할 수 없습니다. RBAC-shared 보안 그룹을 인스턴스에 적용하려면 먼저 포트를 생성하고, 공유 보안 그룹을 해당 포트에 적용한 다음 해당 포트를 인스턴스에 할당해야 합니다. 포트에 보안 그룹 추가를 참조하십시오.

사전 요구 사항

  • 공유하려는 RHOSP 프로젝트는 두 개 이상 있습니다.
  • 프로젝트 중 하나에서 현재 프로젝트인 다른 프로젝트인 대상 프로젝트와 공유할 보안 그룹을 생성했습니다.

    이 예에서는 ping_ssh 보안 그룹이 생성됩니다.

    예제

    $ openstack security group create ping_ssh

절차

  1. 보안 그룹이 포함된 현재 프로젝트의 오버클라우드에 로그인합니다.
  2. 대상 프로젝트의 이름 또는 ID를 가져옵니다.

    $ openstack project list
  3. RHOSP 프로젝트 간에 공유할 보안 그룹의 이름 또는 ID를 가져옵니다.

    $ openstack security group list
  4. 이전 단계의 식별자를 사용하여 openstack network rbac create 명령을 사용하여 RBAC 정책을 생성합니다.

    이 예에서 대상 프로젝트의 ID는 32016615de5d43bb88de99e7f2e26a1e 26a1e입니다. 보안 그룹의 ID는 5ba835b7-22b0-4be6-bdbe-e0722d1b5f24:

    예제

    $ openstack network rbac create --target-project \
    32016615de5d43bb88de99e7f2e26a1e --action access_as_shared \
    --type security_group 5ba835b7-22b0-4be6-bdbe-e0722d1b5f24

    --target-project

    보안 그룹에 액세스해야 하는 프로젝트를 지정합니다.

    작은 정보

    --target-project <target-project> 대신 --target- all -projects 인수를 사용하여 모든 프로젝트 간에 데이터를 공유할 수 있습니다. 기본적으로 admin 사용자만 이 권한을 갖습니다.

    --action access_as_shared
    프로젝트에서 수행할 수 있는 작업을 지정합니다.
    --type
    대상 개체가 보안 그룹임을 나타냅니다.
    5ba835b7-22b0-4be6-bdbe-e0722d1b5f24
    액세스 권한이 부여된 특정 보안 그룹의 ID입니다.

대상 프로젝트는 OpenStack Client 보안 그룹 명령을 실행할 때 해당 포트에 바인딩할 수 있을 때 보안 그룹에 액세스할 수 있습니다. 다른 사용자(관리자 및 소유자 이외의)는 보안 그룹에 액세스할 수 없습니다.

작은 정보

대상 프로젝트에 대한 액세스를 제거하려면 openstack network rbac delete 명령을 사용하여 허용하는 RBAC 정책을 삭제합니다.

추가 리소스

19장. 계층 3 고가용성(HA) 구성

19.1. 고가용성(HA)이 없는 RHOSP Networking 서비스

HA(고가용성) 기능이 없는 RHOSP(Red Hat OpenStack Platform) 네트워킹 서비스 배포는 물리적 노드 장애에 취약합니다.

일반적인 배포에서는 프로젝트에서 물리 네트워킹 서비스 계층 3(L3) 에이전트 노드에서 실행되도록 예약된 가상 라우터를 생성합니다. L3 에이전트 노드가 끊어지고 종속 가상 시스템이 결과적으로 외부 네트워크에 대한 연결이 끊어지면 문제가 됩니다. 부동 IP 주소도 사용할 수 없습니다. 또한 라우터 호스트가하는 네트워크 간에 연결이 끊어집니다.

19.2. 계층 3 고가용성(HA) 개요

이 활성/수동 고가용성(HA) 구성에서는 RFC 3768에 정의된 업계 표준 VRRP를 사용하여 프로젝트 라우터 및 유동 IP 주소를 보호합니다. 가상 라우터는 여러 RHOSP(Red Hat OpenStack Platform) 네트워킹 서비스 노드에 무작위로 예약되며, 하나는 활성 라우터로 지정되고 나머지 라우터는 Hive 역할로 제공됩니다.

참고

계층 3(L3) HA를 배포하려면 유동 IP 범위 및 외부 네트워크에 대한 액세스를 포함하여 중복된 네트워킹 서비스 노드에서 유사한 구성을 유지해야 합니다.

다음 다이어그램에서는 활성 Router1Router2 라우터가 별도의 물리 L3 Networking 서비스 에이전트 노드에서 실행되고 있습니다. L3 HA는 해당 노드에 백업 가상 라우터를 예약하고 물리적 노드 장애가 발생하는 경우 서비스를 다시 시작할 준비가 되었습니다. L3 에이전트 노드가 실패하면 L3 HA는 영향을 받는 가상 라우터 및 유동 IP 주소를 작동 중인 노드로 다시 예약합니다.

고가용성 L3 네트워크

장애 조치(failover) 이벤트 중에 유동 IP를 통한 인스턴스 TCP 세션에 영향을 미치지 않고 새 L3 노드로 마이그레이션됩니다. SNAT 트래픽만 장애 조치 이벤트의 영향을 받습니다.

L3 에이전트는 활성/활성 HA 모드의 경우 추가로 보호됩니다.

19.3. 계층 3 HA(고가용성) 장애 조치 조건

RHOSP(Red Hat OpenStack Platform) 네트워킹 서비스의 계층 3 HA(고가용성)는 다음 이벤트에서 보호된 리소스를 자동으로 다시 스케줄링합니다.

  • 네트워킹 서비스 L3 에이전트 노드가 종료되거나 하드웨어 장애로 인해 전원이 끊어집니다.
  • L3 에이전트 노드는 물리적 네트워크와 분리되고 연결이 끊어집니다.
참고

L3 에이전트 서비스를 수동으로 중지해도 장애 조치(failover) 이벤트가 발생하지 않습니다.

19.4. 계층 3 고가용성(HA)에 대한 프로젝트 고려 사항

RHOSP(Red Hat OpenStack Platform) 네트워킹 서비스 계층 3(L3) HA(고가용성) 구성은 백엔드에서 수행되며 프로젝트에 표시되지 않습니다. 프로젝트는 일반적으로 가상 라우터를 생성하고 관리할 수 있지만 L3 HA 구현을 설계할 때 몇 가지 제한 사항이 있습니다.

  • L3 HA는 프로젝트당 최대 255개의 가상 라우터를 지원합니다.
  • 내부 VRRP 메시지는 각 프로젝트에 대해 자동으로 생성된 별도의 내부 네트워크 내에서 전송됩니다. 이 프로세스는 사용자에게 투명하게 이루어집니다.
  • ML2/OVS에서 HA(고가용성) 라우터를 구현할 때 각 L3 에이전트는 각 라우터에 대해 haproxyneutron-keepalived-state-change-monitor 프로세스를 생성합니다. 각 프로세스는 약 20MB의 메모리를 사용합니다. 기본적으로 각 HA 라우터는 3개의 L3 에이전트에 있으며 각 노드에서 리소스를 사용합니다. 따라서 RHOSP 네트워크를 크기 조정할 때 구현하려는 HA 라우터 수를 지원하기에 충분한 메모리를 할당해야 합니다.

19.5. RHOSP 네트워킹 서비스의 고가용성(HA) 변경

RHOSP(Red Hat OpenStack Platform) 네트워킹 서비스(neutron) API가 업데이트되어 관리자가 라우터를 생성할 때 --ha=True/False 플래그를 설정할 수 있습니다. 이 플래그는 /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf 에서 l3_ha 의 기본 구성을 덮어씁니다.

  • 고가용성(HA)을 neutron-server로 변경합니다.

    • 계층 3(L3) HA는 네트워킹 서비스에서 사용하는 스케줄러(random 또는 leastrouter)에 관계없이 active 역할을 무작위로 할당합니다.
    • 데이터베이스 스키마는 가상 라우터에 VIP(가상 IP 주소) 할당을 처리하도록 수정되었습니다.
    • L3 HA 트래픽에 대한 전송 네트워크가 생성됩니다.
  • 네트워킹 서비스 L3 에이전트로 HA 변경:

    • 새로운 keepalived 관리자가 추가되어 로드 밸런싱 및 HA 기능을 제공합니다.
    • IP 주소는 VIP로 변환됩니다.

19.6. RHOSP Networking 서비스 노드에서 계층 3 HA(고가용성) 활성화

설치 중에 RHOSP(Red Hat OpenStack Platform) director는 두 개 이상의 RHOSP 컨트롤러가 있고 DVR(분산 가상 라우팅)을 사용하지 않는 경우 기본적으로 가상 라우터에 HA(고가용성)를 활성화합니다. RHOSP Orchestration 서비스(heat) 매개변수 max_l3_agents_per_router 를 사용하여 HA 라우터가 예약된 RHOSP Networking 서비스 계층 3(L3) 에이전트의 최대 수를 설정할 수 있습니다.

사전 요구 사항

  • RHOSP 배포에서는 DVR을 사용하지 않습니다.
  • 두 개 이상의 RHOSP 컨트롤러가 배포되어 있습니다.

절차

  1. stack 사용자로 언더클라우드에 로그인하고 stackrc 파일을 가져와 director 명령행 툴을 활성화합니다.

    예제

    $ source ~/stackrc

  2. 사용자 지정 YAML 환경 파일을 생성합니다.

    예제

    $ vi /home/stack/templates/my-neutron-environment.yaml

    작은 정보

    오케스트레이션 서비스(heat)는 templates 라는 계획 세트를 사용하여 환경을 설치하고 구성합니다. 사용자 지정 환경 파일을 사용하여 오버클라우드의 특정 부분을 사용자 지정할 수 있습니다. 이 파일은 heat 템플릿에 대한 사용자 지정 사용자 지정을 제공하는 특수한 유형의 템플릿입니다.

  3. YAML 환경 파일에서 NeutronL3HA 매개변수를 true 로 설정합니다. 이렇게 하면 director가 기본적으로 설정되지 않은 경우에도 HA가 활성화됩니다.

    parameter_defaults:
      NeutronL3HA: 'true'
  4. HA 라우터가 예약된 최대 L3 에이전트 수를 설정합니다.

    max_l3_agents_per_router 매개변수를 배포의 최소 및 총 네트워크 노드 수 사이의 값으로 설정합니다. (0 값은 라우터가 모든 에이전트에 예약됨을 나타냅니다.)

    예제

    parameter_defaults:
      NeutronL3HA: 'true'
      ControllerExtraConfig:
        neutron::server::max_l3_agents_per_router: 2

    이 예제에서는 4개의 네트워킹 서비스 노드를 배포하는 경우 두 개의 L3 에이전트만 각 HA 가상 라우터(활성 1개, 하나의 active)를 보호합니다.

    max_l3_agents_per_router 값을 사용 가능한 네트워크 노드 수보다 크게 설정하면 새 L3 에이전트를 추가하여 CoreDNS 라우터 수를 확장할 수 있습니다. 배포하는 모든 새로운 L3 에이전트 노드의 경우 Networking 서비스는 max_l3_agents_per_router 제한에 도달할 때까지 가상 라우터의 추가ECDHE 버전을 예약합니다.

  5. openstack overcloud deploy 명령을 실행하고 코어 heat 템플릿, 환경 파일 및 이 새 사용자 지정 환경 파일을 포함합니다.

    중요

    후속 환경 파일에 정의된 매개 변수와 리소스가 우선하므로 환경 파일의 순서가 중요합니다.

    예제

    $ openstack overcloud deploy --templates \
    -e [your-environment-files] \
    -e /usr/share/openstack-tripleo-heat-templates/environments/services/my-neutron-environment.yaml

    참고

    NeutronL3HAtrue 로 설정되면 기본적으로 생성된 모든 가상 라우터는 HA 라우터로 설정됩니다. 라우터를 생성할 때 openstack router create 명령에 --no-ha 옵션을 포함하여 HA 옵션을 덮어쓸 수 있습니다.

    # openstack router create --no-ha

추가 리소스

19.7. HA(고가용성) RHOSP Networking 서비스 노드 구성 검토

절차

  • 가상 라우터 네임스페이스에서 ip address 명령을 실행하여 ha- 접두사가 붙은 HA(고가용성) 장치를 반환합니다.

    # ip netns exec qrouter-b30064f9-414e-4c98-ab42-646197c74020 ip address
    <snip>
    2794: ha-45249562-ec: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 12:34:56:78:2b:5d brd ff:ff:ff:ff:ff:ff
    inet 169.254.0.2/24 brd 169.254.0.255 scope global ha-54b92d86-4f

계층 3 HA를 활성화하면 가상 라우터 및 유동 IP 주소가 개별 노드 장애로부터 보호됩니다.

20장. 가용 영역을 사용하여 네트워크 리소스를 고가용성으로 만들기

버전 16.2부터 RHOSP(Red Hat OpenStack Platform)는 RHOSP Networking 서비스(neutron) 가용 영역(AZ)을 지원합니다.

AZ를 사용하면 RHOSP 네트워크 리소스를 고가용성으로 만들 수 있습니다. 다른 AZ의 다른 전원 소스에 연결된 네트워크 노드를 그룹화한 다음 중요한 서비스를 별도의 AZ에 예약할 수 있습니다.

종종 네트워킹 서비스 AZ는 Compute 서비스(nova) AZ와 함께 사용되어 고객이 워크로드가 실행되는 물리적 사이트에 로컬인 특정 가상 네트워크를 사용하도록 합니다. 분산 컴퓨팅 노드 아키텍처에 대한 자세한 내용은 분산 컴퓨팅 노드 및 스토리지 배포 가이드를 참조하십시오.

20.1. Networking 서비스 가용성 영역 정보

RHOSP(Red Hat OpenStack Platform) 네트워킹 서비스(neutron) 가용 영역(AZ) 기능을 제공하는 필수 확장 기능은 availability_zone,router_availability_zone, network_availability_zone 입니다. Open vSwitch(ML2/OVS) 메커니즘 드라이버가 있는 Modular Layer 2 플러그인은 이러한 모든 확장을 지원합니다.

참고

Open Virtual Network(ML2/OVN) 메커니즘 드라이버가 있는 Modular Layer 2 플러그인은 라우터 가용성 영역만 지원합니다. ML2/OVN에는 분산 DHCP 서버가 있으므로 AZ를 지원하는 것은 필요하지 않습니다.

네트워크 리소스를 생성할 때 OpenStack 클라이언트 명령줄 옵션 --availability-zone-hint 를 사용하여 AZ를 지정할 수 있습니다. 지정한 AZ가 AZ 힌트 목록에 추가됩니다. 그러나 리소스를 예약할 때까지 AZ 속성은 실제로 설정되지 않습니다. 네트워크 리소스에 할당된 실제 AZ는 힌트 옵션으로 지정한 AZ와 다를 수 있습니다. 이러한 불일치의 원인은 영역 오류가 있거나 지정된 영역에 남아 있는 용량이 남아 있지 않기 때문일 수 있습니다.

네트워크 리소스를 생성할 때 사용자가 AZ를 지정하지 못하는 경우 기본 AZ에 대한 네트워킹 서비스를 구성할 수 있습니다. 기본 AZ를 설정하는 것 외에도 AZ에서 네트워크 및 라우터를 예약하도록 특정 드라이버를 구성할 수도 있습니다.

20.2. ML2/OVS의 네트워크 서비스 가용성 영역 구성

사용자가 네트워크 및 라우터를 생성할 때 RHOSP(Red Hat OpenStack Platform) 네트워킹 서비스(neutron)에서 자동으로 할당하는 하나 이상의 기본 가용성 영역(AZ)을 설정할 수 있습니다. 또한 네트워킹 서비스에서 해당 AZ에 대해 이러한 리소스를 예약하는 데 사용하는 네트워크 및 라우터 드라이버를 설정할 수도 있습니다.

이 항목에 포함된 정보는 Open vSwitch 메커니즘 드라이버(ML2/OVS)와 함께 모듈 계층 2 플러그인을 사용하는 RHOSP 네트워킹 서비스를 실행하는 배포를 위한 것입니다.

사전 요구 사항

  • RHOSP 16.2 이상을 배포합니다.
  • ML2/OVS 메커니즘 드라이버를 사용하는 RHOSP 네트워킹 서비스 실행.
  • DCN(Distributed Compute Node) 환경에서 네트워킹 서비스 AZ를 사용하는 경우 Networking 서비스 AZ 이름과 Compute 서비스(nova) AZ 이름과 일치해야 합니다.

    자세한 내용은 분산 컴퓨팅 노드 및 스토리지 배포 가이드를 참조하십시오.

절차

  1. stack 사용자로 언더클라우드에 로그인하고 stackrc 파일을 소싱하여 director 명령행 툴을 활성화합니다.

    예제

    $ source ~/stackrc

  2. 사용자 지정 YAML 환경 파일을 생성합니다.

    예제

    $ vi /home/stack/templates/my-neutron-environment.yaml

    작은 정보

    Red Hat OpenStack Platform Orchestration 서비스(heat)는 템플릿 이라는 일련의 계획을 사용하여 환경을 설치하고 구성합니다. 사용자 지정 환경 파일을 사용하여 오버클라우드의 특정 부분을 사용자 지정할 수 있습니다. 이 파일은 heat 템플릿에 대한 사용자 지정 사용자 지정을 제공하는 특수한 유형의 템플릿입니다.

  3. YAML 환경 파일의 parameter_defaults 에서 NeutronDefaultAvailabilityZones 매개변수와 하나 이상의 AZ를 입력합니다. 네트워크 또는 라우터를 생성할 때 사용자가 --availability-zone-hint 옵션을 사용하여 AZ를 지정하지 못하는 경우 네트워킹 서비스는 이러한 AZ를 할당합니다.

    중요

    DCN 환경에서는 Networking 서비스 AZ 이름과 Compute 서비스 AZ 이름과 일치해야 합니다.

    예제

    parameter_defaults:
      NeutronDefaultAvailabilityZones: 'az-central,az-datacenter2,az-datacenter1'

  4. NeutronDhcpAgentAvailabilityZoneNeutronL3AgentAvailabilityZone 에 대한 값을 각각 입력하여 DHCP 및 L3 에이전트의 AZ를 결정합니다.

    예제

    parameter_defaults:
      NeutronDefaultAvailabilityZones: 'az-central,az-datacenter2,az-datacenter1'
      NeutronL3AgentAvailabilityZone: 'az-central,az-datacenter2,az-datacenter1'
      NeutronDhcpAgentAvailabilityZone: 'az-central,az-datacenter2,az-datacenter1'

    중요

    DCN 환경에서는 NeutronDhcpAgentAvailabilityZone 에 대한 단일 AZ를 정의하여 특정 엣지 사이트와 관련된 AZ에서 포트가 예약되도록 합니다.

  5. 기본적으로 네트워크 및 라우터 스케줄러는 AZAwareWeightSchedulerAZLeastRoutersScheduler 입니다. 이 중 하나 또는 둘 다를 변경하려면 각각 NeutronNetworkSchedulerDriverNeutronRouterSchedulerDriver 매개변수를 사용하여 새 스케줄러를 입력합니다.

    예제

    parameter_defaults:
      NeutronDefaultAvailabilityZones: 'az-central,az-datacenter2,az-datacenter1'
      NeutronL3AgentAvailabilityZone: 'az-central,az-datacenter2,az-datacenter1'
      NeutronDhcpAgentAvailabilityZone: 'az-central,az-datacenter2,az-datacenter1'
      NeutronNetworkSchedulerDriver: 'neutron.scheduler.dhcp_agent_scheduler.AZAwareWeightScheduler'
      NeutronRouterSchedulerDriver: 'neutron.scheduler.l3_agent_scheduler.AZLeastRoutersScheduler'

  6. openstack overcloud deploy 명령을 실행하고 코어 heat 템플릿, 환경 파일 및 이 새 사용자 지정 환경 파일을 포함합니다.

    중요

    후속 환경 파일에 정의된 매개 변수와 리소스가 우선하므로 환경 파일의 순서가 중요합니다.

    예제

    $ openstack overcloud deploy --templates \
    -e <your-environment-files> \
    -e /usr/share/openstack-tripleo-heat-templates/environments/services/\
    my-neutron-environment.yaml

검증

  • 가용성 영역 목록 명령을 실행하여 가용성 영역이 올바르게 정의되었는지 확인합니다.

    예제

    $ openstack availability zone list

    샘플 출력

    +----------------+-------------+
    | Zone Name      | Zone Status |
    +----------------+-------------+
    | az-central     | available   |
    | az-datacenter1 | available   |
    | az-datacenter2 | available   |
    +----------------+-------------+

20.3. ML2/OVN으로 네트워크 서비스 가용성 영역 구성

사용자가 라우터를 생성할 때 RHOSP(Red Hat OpenStack Platform) 네트워킹 서비스(neutron)에서 자동으로 할당하는 하나 이상의 기본 가용성 영역(AZ)을 설정할 수 있습니다. 또한 네트워킹 서비스에서 해당 AZ에 대해 이러한 리소스를 예약하는 데 사용하는 라우터 드라이버를 설정할 수도 있습니다.

이 항목에 포함된 정보는 ML2/OVN(Open Virtual Network) 메커니즘 드라이버와 함께 Modular Layer 2 플러그인을 사용하는 RHOSP Networking 서비스를 실행하는 배포에 사용됩니다.

참고

ML2/OVN 메커니즘 드라이버는 라우터 가용성 영역만 지원합니다. ML2/OVN에는 분산 DHCP 서버가 있으므로 AZ를 지원하는 것은 필요하지 않습니다.

사전 요구 사항

  • RHOSP 16.2 이상을 배포합니다.
  • ML2/OVN 메커니즘 드라이버를 사용하는 RHOSP 네트워킹 서비스 실행.
  • DCN(Distributed Compute Node) 환경에서 네트워킹 서비스 AZ를 사용하는 경우 Networking 서비스 AZ 이름과 Compute 서비스(nova) AZ 이름과 일치해야 합니다.

    자세한 내용은 분산 컴퓨팅 노드 및 스토리지 배포 가이드를 참조하십시오.

절차

  1. stack 사용자로 언더클라우드에 로그인하고 stackrc 파일을 가져와 director 명령행 툴을 활성화합니다.

    예제

    $ source ~/stackrc

  2. 사용자 지정 YAML 환경 파일을 생성합니다.

    예제

    $ vi /home/stack/templates/my-neutron-environment.yaml

    작은 정보

    Red Hat OpenStack Platform Orchestration 서비스(heat)는 템플릿 이라는 일련의 계획을 사용하여 환경을 설치하고 구성합니다. 사용자 지정 환경 파일을 사용하여 오버클라우드의 특정 부분을 사용자 지정할 수 있습니다. 이 파일은 heat 템플릿에 대한 사용자 지정 사용자 지정을 제공하는 특수한 유형의 템플릿입니다.

  3. YAML 환경 파일의 parameter_defaults 에서 NeutronDefaultAvailabilityZones 매개변수와 하나 이상의 AZ를 입력합니다.

    중요

    DCN 환경에서는 Networking 서비스 AZ 이름과 Compute 서비스 AZ 이름과 일치해야 합니다.

    네트워킹 서비스는 사용자가 네트워크 또는 라우터를 생성할 때 --availability-zone-hint 옵션으로 AZ를 지정하지 못하는 경우 이러한 AZ를 할당합니다.

    예제

    parameter_defaults:
      NeutronDefaultAvailabilityZones: 'az-central,az-datacenter2,az-datacenter1'

  4. 매개변수인 OVNAvailabilityZone 에 대한 값을 입력하여 게이트웨이 노드(Controller 및 Network 노드)의 AZ를 확인합니다.

    중요

    OVNAvailability 매개변수는 OVNCMSOptions 매개변수에서 AZ 값의 사용을 대체합니다. OVNAvailability 매개변수를 사용하는 경우 OVNCMSOptions 매개변수에 AZ 값이 없는지 확인합니다.

    예제

    이 예에서는 az-central AZ의 Controller에 대한 역할이 사전 정의되어 있으며 datacenter1datacenter2 AZ의 Networkers가 다음과 같습니다.

    parameter_defaults:
      NeutronDefaultAvailabilityZones: 'az-central,az-datacenter2,az-datacenter1'
      ControllerCentralParameters:
        OVNCMSOptions: 'enable-chassis-as-gw'
        OVNAvailabilityZone: 'az-central,az-datacenter2,az-datacenter1'
      NetworkerDatacenter1Parameters:
        OVNCMSOptions: 'enable-chassis-as-gw'
        OVNAvailabilityZone: 'az-datacenter1'
      NetworkerDatacenter2Parameters:
        OVNCMSOptions: 'enable-chassis-as-gw'
        OVNAvailabilityZone: 'az-datacenter2'
    중요

    DCN 환경에서는 ControllerCentralParameter 에 대한 단일 AZ를 정의하여 포트가 특정 에지 사이트와 관련된 AZ에 예약되도록 합니다.

  5. 기본적으로 라우터 스케줄러는 AZLeastRoutersScheduler 입니다. 이 값을 변경하려면 NeutronRouterSchedulerDriver 매개변수를 사용하여 새 스케줄러를 입력합니다.

    예제

    parameter_defaults:
      NeutronDefaultAvailabilityZones: 'az-central,az-datacenter2,az-datacenter1'
      ControllerCentralParameters:
        OVNCMSOptions: 'enable-chassis-as-gw'
        OVNAvailabilityZone: 'az-central,az-datacenter2,az-datacenter1'
      NetworkerDCN1Parameters:
        OVNCMSOptions: 'enable-chassis-as-gw'
        OVNAvailabilityZone: 'az-datacenter1'
      NetworkerDCN2Parameters:
        OVNCMSOptions: 'enable-chassis-as-gw'
        OVNAvailabilityZone: 'az-datacenter2'
      NeutronRouterSchedulerDriver: 'neutron.scheduler.l3_agent_scheduler.AZLeastRoutersScheduler'

  6. openstack overcloud deploy 명령을 실행하고 코어 heat 템플릿, 환경 파일 및 이 새 사용자 지정 환경 파일을 포함합니다.

    중요

    후속 환경 파일에 정의된 매개 변수와 리소스가 우선하므로 환경 파일의 순서가 중요합니다.

    예제

    $ openstack overcloud deploy --templates \
    -e <your-environment-files> \
    -e /usr/share/openstack-tripleo-heat-templates/environments/services/\
    my-neutron-environment.yaml

검증

  • 가용성 영역 목록 명령을 실행하여 가용성 영역이 올바르게 정의되었는지 확인합니다.

    예제

    $ openstack availability zone list

    샘플 출력

    +----------------+-------------+
    | Zone Name      | Zone Status |
    +----------------+-------------+
    | az-central     | available   |
    | az-datacenter1 | available   |
    | az-datacenter2 | available   |
    +----------------+-------------+

20.4. 네트워크 및 라우터에 가용성 영역 수동 할당

RHOSP 네트워크 또는 라우터를 생성할 때 RHOSP(Red Hat OpenStack Platform) 네트워킹 서비스(neutron) 가용 영역(AZ)을 수동으로 할당할 수 있습니다. AZ를 사용하면 RHOSP 네트워크 리소스를 고가용성으로 만들 수 있습니다. 다른 AZ의 다른 전원 소스에 연결된 네트워크 노드를 그룹화한 다음 중요한 서비스를 실행하는 노드를 별도의 AZ에 배치할 수 있습니다.

참고

네트워크 또는 라우터를 생성할 때 AZ를 지정하지 않으면 RHOSP Networking 서비스에서 리소스에 RHOSP Orchestration 서비스(heat) 매개변수에 지정된 값을 자동으로 할당합니다. NeutronDefaultAvailabilityZones 에 대해 값이 정의되지 않은 경우 AZ 속성 없이 리소스를 예약합니다.

Open vSwitch(ML2/OVS) 메커니즘 드라이버와 함께 Modular Layer 2 플러그인을 사용하는 RHOSP Networking 서비스 에이전트의 경우 AZ 힌트가 제공되지 않고 NeutronDefaultAvailabilityZones 에 지정된 값이 없는 경우, 에이전트 예약에 Compute 서비스(nova) AZ 값을 사용합니다.

사전 요구 사항

  • RHOSP 16.2 이상을 배포합니다.
  • ML2/OVS 또는 ML2/OVN(Open Virtual Network) 메커니즘 드라이버를 사용하는 RHOSP 네트워킹 서비스 실행

절차

  • OpenStack 클라이언트를 사용하여 오버클라우드에서 네트워크를 생성할 때 --availability-zone-hint 옵션을 사용합니다.

    참고

    ML2/OVN 메커니즘 드라이버는 라우터 가용성 영역만 지원합니다. ML2/OVN에는 분산 DHCP 서버가 있으므로 AZ를 지원하는 것은 필요하지 않습니다.

    다음 예에서 네트워크(net1)가 생성되고 AZ zone-1 또는 zone-2 에 할당됩니다.

    네트워크 예

    $ openstack network create --availability-zone-hint zone-1 \
    --availability-zone-hint zone-2 net1

    샘플 출력

    +---------------------------+--------------------------------------+
    | Field                     | Value                                |
    +---------------------------+--------------------------------------+
    | admin_state_up            | UP                                   |
    | availability_zone_hints   | zone-1                               |
    |                           | zone-2                               |
    | availability_zones        |                                      |
    | created_at                | 2021-07-31T22:14:12Z                 |
    | description               |                                      |
    | headers                   |                                      |
    | id                        | ad88e059-e7fa-4cf7-8857-6731a2a3a554 |
    | ipv4_address_scope        | None                                 |
    | ipv6_address_scope        | None                                 |
    | mtu                       | 1450                                 |
    | name                      | net1                                 |
    | port_security_enabled     | True                                 |
    | project_id                | cfd1889ac7d64ad891d4f20aef9f8d7c     |
    | provider:network_type     | vxlan                                |
    | provider:physical_network | None                                 |
    | provider:segmentation_id  | 77                                   |
    | revision_number           | 3                                    |
    | router:external           | Internal                             |
    | shared                    | False                                |
    | status                    | ACTIVE                               |
    | subnets                   |                                      |
    | tags                      | []                                   |
    | updated_at                | 2021-07-31T22:14:13Z                 |
    +---------------------------+--------------------------------------+

  • OpenStack 클라이언트를 사용하여 오버클라우드에 라우터를 생성할 때 --ha 및 -- availability-zone-hint 옵션을 사용합니다.

    다음 예에서 라우터(router1)가 생성되고 AZ zone-1 또는 zone-2 에 할당됩니다.

    라우터 예

    $ openstack router create --ha --availability-zone-hint zone-1 \
    --availability-zone-hint zone-2 router1

    샘플 출력

    +-------------------------+--------------------------------------+
    | Field                   | Value                                |
    +-------------------------+--------------------------------------+
    | admin_state_up          | UP                                   |
    | availability_zone_hints | zone-1                               |
    |                         | zone-2                               |
    | availability_zones      |                                      |
    | created_at              | 2021-07-31T22:16:54Z                 |
    | description             |                                      |
    | distributed             | False                                |
    | external_gateway_info   | null                                 |
    | flavor_id               | None                                 |
    | ha                      | False                                |
    | headers                 |                                      |
    | id                      | ced10262-6cfe-47c1-8847-cd64276a868c |
    | name                    | router1                              |
    | project_id              | cfd1889ac7d64ad891d4f20aef9f8d7c     |
    | revision_number         | 3                                    |
    | routes                  |                                      |
    | status                  | ACTIVE                               |
    | tags                    | []                                   |
    | updated_at              | 2021-07-31T22:16:56Z                 |
    +-------------------------+--------------------------------------+

    네트워크 리소스를 만들 때 실제 AZ가 할당되지 않습니다. RHOSP 네트워킹 서비스는 리소스를 예약할 때 AZ를 할당합니다.

검증

  • 적절한 OpenStack 클라이언트 show 명령을 입력하여 리소스가 호스팅되는 영역을 확인합니다.

    예제

    $ openstack network show net1

    샘플 출력

    +---------------------------+--------------------------------------+
    | Field                     | Value                                |
    +---------------------------+--------------------------------------+
    | admin_state_up            | UP                                   |
    | availability_zone_hints   | zone-1                               |
    |                           | zone-2                               |
    | availability_zones        | zone-1                               |
    |                           | zone-2                               |
    | created_at                | 2021-07-31T22:14:12Z                 |
    | description               |                                      |
    | headers                   |                                      |
    | id                        | ad88e059-e7fa-4cf7-8857-6731a2a3a554 |
    | ipv4_address_scope        | None                                 |
    | ipv6_address_scope        | None                                 |
    | mtu                       | 1450                                 |
    | name                      | net1                                 |
    | port_security_enabled     | True                                 |
    | project_id                | cfd1889ac7d64ad891d4f20aef9f8d7c     |
    | provider:network_type     | vxlan                                |
    | provider:physical_network | None                                 |
    | provider:segmentation_id  | 77                                   |
    | revision_number           | 3                                    |
    | router:external           | Internal                             |
    | shared                    | False                                |
    | status                    | ACTIVE                               |
    | subnets                   |                                      |
    | tags                      | []                                   |
    | updated_at                | 2021-07-31T22:14:13Z                 |
    +---------------------------+--------------------------------------+

21장. 태그가 있는 가상 장치 식별

21.1. 가상 장치 태그

Red Hat OpenStack Platform에서 여러 네트워크 인터페이스 또는 블록 장치가 있는 VM 인스턴스를 시작하는 경우 장치 태그를 사용하여 각 장치의 의도한 역할을 인스턴스 운영 체제와 전달할 수 있습니다. 태그는 인스턴스 부팅 시 장치에 할당되며 메타데이터 API 및 구성 드라이브(활성화된 경우)를 통해 인스턴스 운영 체제에서 사용할 수 있습니다.

절차

  • 가상 장치에 태그를 지정하려면 인스턴스를 생성할 때 태그 매개 변수 --block-device--nic 을 사용합니다.

    예제

    $ nova boot test-vm --flavor m1.tiny --image cirros \
    --nic net-id=55411ca3-83dd-4036-9158-bf4a6b8fb5ce,tag=nfv1 \
    --block-device id=b8c9bef7-aa1d-4bf4-a14d-17674b370e13,bus=virtio,tag=database-server NFVappServer

    결과 태그는 기존 인스턴스 메타데이터에 추가되고 메타데이터 API와 구성 드라이브 모두를 통해 사용할 수 있습니다.

    이 예에서 다음 devices 섹션은 메타데이터를 채웁니다.

    meta_data.json 파일의 샘플 콘텐츠:

        {
      "devices": [
        {
            "type": "nic",
            "bus": "pci",
            "address": "0030:00:02.0",
            "mac": "aa:00:00:00:01",
            "tags": ["nfv1"]
        },
        {
            "type": "disk",
            "bus": "pci",
            "address": "0030:00:07.0",
            "serial": "disk-vol-227",
            "tags": ["database-server"]
        }
      ]
    }

    장치 태그 메타데이터는 메타데이터 API에서 GET /openstack/latest/meta_data.json 을 사용하여 사용할 수 있습니다.

    구성 드라이브가 활성화되고 인스턴스 운영 체제의 /configdrive 아래에 마운트된 경우 메타데이터도 /configdrive/openstack/latest/meta_data.json 에 있습니다.

법적 공지

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.