Red Hat OpenDaylight 설치 및 구성 가이드
Red Hat OpenStack Platform을 사용하여 OpenDaylight 설치 및 구성
초록
머리말 링크 복사링크가 클립보드에 복사되었습니다!
이 문서에서는 OpenDaylight 소프트웨어 정의 네트워크(SDN) 컨트롤러를 사용하여 Red Hat OpenStack Platform 13을 배포하는 방법을 설명합니다. OpenDaylight 컨트롤러는 neutron ML2/OVS 플러그인 및 L2 및 L3 에이전트의 드롭인 대체이며 Red Hat OpenStack 환경 내에서 네트워크 가상화를 제공합니다.
1장. 개요 링크 복사링크가 클립보드에 복사되었습니다!
1.1. OpenDaylight는 무엇입니까? 링크 복사링크가 클립보드에 복사되었습니다!
OpenDaylight 플랫폼은 OpenStack 환경을 위한 네트워크 가상화에 사용할 수 있는 Java로 작성된 프로그래밍 가능한 SDN 컨트롤러입니다. 컨트롤러 아키텍처는 분리된 northbound 및 southbound 인터페이스로 구성됩니다. OpenStack 통합을 위해 기본 northbound 인터페이스는 OpenStack Networking 서비스인 neutron과 통신하는 NeutronNorthbound 프로젝트를 사용합니다. OVSDB 및 OpenFlow 플러그인인 southbound OpenDaylight 프로젝트는 OVS( Open vSwitch ) 컨트롤 및 데이터 플레인과 통신하는 데 사용됩니다. Neutron 구성을 네트워크 가상화로 변환하는 기본 OpenDaylight 프로젝트는 NetVirt 프로젝트입니다.
1.2. OpenDaylight는 OpenStack에서 어떻게 작동합니까? 링크 복사링크가 클립보드에 복사되었습니다!
1.2.1. 기본 neutron 아키텍처 링크 복사링크가 클립보드에 복사되었습니다!
neutron 참조 아키텍처는 일련의 에이전트를 사용하여 OpenStack 내의 네트워크를 관리합니다. 이러한 에이전트는 다른 플러그인으로 neutron에 제공됩니다. 코어 플러그인은 계층 2 오버레이 기술과 데이터 플레인 유형을 관리하는 데 사용됩니다. 서비스 플러그인은 방화벽, DHCP, 라우팅, NAT와 같은 OSI 모델에서 계층 3 이상의 네트워크 작업을 관리하는 데 사용됩니다.
기본적으로 Red Hat OpenStack Platform은 각 컴퓨팅 및 컨트롤러 노드에서 OVS를 구성하는 에이전트를 제공하는 OVS 메커니즘 드라이버와 함께ML2(Modular Layer 2) 코어 플러그인을 사용합니다. 서비스 플러그인인 DHCP 에이전트, 메타데이터 에이전트는 L3 에이전트와 함께 컨트롤러에서 실행됩니다.
1.2.2. OpenDaylight 기반 네트워킹 아키텍처 링크 복사링크가 클립보드에 복사되었습니다!
OpenDaylight는 networking-odl 이라는 자체 드라이버를 제공하여 ML2 코어 플러그인과 통합됩니다. 따라서 모든 노드에서 OVS 에이전트를 사용할 필요가 없습니다. OpenDaylight는 개별 노드에서 에이전트가 없어도 각 OVS 인스턴스를 환경에서 직접 프로그래밍할 수 있습니다. 계층 3 서비스의 경우 neutron은 OpenDaylight L3 플러그인을 사용하도록 구성되어 있습니다. 이러한 접근 방식을 사용하면 OpenDaylight가 데이터 플레인을 직접 프로그래밍하여 분산 가상 라우팅 기능을 처리할 수 있기 때문에 라우팅 및 NAT(네트워크 주소 변환)를 처리하는 여러 노드의 에이전트 수가 줄어듭니다. neutron DHCP 및 메타데이터 에이전트는 여전히 DHCP 및 메타데이터(cloud-init) 요청을 관리하는 데 사용됩니다.
OpenDaylight는 DHCP 서비스를 제공합니다. 그러나 현재 Red Hat OpenStack Platform director 아키텍처를 배포할 때 neutron DHCP 에이전트를 사용하면 HA(고가용성) 및 가상 머신(VM) 인스턴스 메타데이터(cloud-init)에 대한 지원을 제공하므로 Red Hat은 이러한 기능에 대해 OpenDaylight를 사용하지 않고 neutron DHCP 에이전트를 배포할 것을 권장합니다.
1.3. Red Hat OpenStack Platform director란 무엇이며 어떻게 설계됩니까? 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat OpenStack Platform director는 완전한 OpenStack 환경을 설치하고 관리하기 위한 툴셋입니다. 주로 OpenStack TripleO (OpenStack-On-OpenStack) 프로젝트를 기반으로 합니다.
이 프로젝트는 OpenStack 구성 요소를 사용하여 완전히 작동하는 OpenStack 환경을 설치합니다. 또한 베어 메탈 시스템을 프로비저닝하고 OpenStack 노드로 작동하는 새로운 OpenStack 구성 요소가 포함되어 있습니다. 이 방법을 사용하면 가볍고 강력한 완전한 Red Hat OpenStack Platform 환경을 설치할 수 있습니다.
Red Hat OpenStack Platform director는 언더클라우드 와 오버클라우드 의 두 가지 주요 개념을 사용합니다. 언더클라우드에서 오버클라우드를 설치 및 구성합니다. Red Hat OpenStack Platform director 아키텍처에 대한 자세한 내용은 Director Installation and Usage 를 참조하십시오.
그림 1.1. Red Hat OpenStack Platform 디렉터 -undercloud 및 오버클라우드
1.3.1. Red Hat OpenStack Platform director 및 OpenDaylight 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat OpenStack Platform director는 구성 가능 서비스 및 사용자 지정 역할에 대한 개념을 도입합니다. 구성 가능 서비스는 필요한 경우 역할별로 포함 및 활성화할 수 있는 격리된 리소스를 형성합니다. 사용자 지정 역할을 통해 사용자는 기본 컨트롤러 및 컴퓨팅 역할과 관계없이 자체 역할을 생성할 수 있습니다. 이제 배포할 OpenStack 서비스와 이를 호스팅할 노드를 선택할 수 있는 옵션이 있습니다.
OpenDaylight를 director와 통합하기 위해 다음 두 가지 서비스가 추가되었습니다.
- OpenDaylight SDN 컨트롤러를 실행하기 위한 OpenDaylightApi 서비스
- OpenDaylight는 각 노드에서 OVS를 설정하여 OpenDaylight와 올바르게 통신할 수 있도록 하는 OpenDaylightOvs 서비스입니다.
기본적으로 OpenDaylightApi 서비스는 컨트롤러 역할에서 실행되며 OpenDaylightOvs 서비스는 컨트롤러 및 Compute 역할에서 실행됩니다. OpenDaylight는 OpenDaylightApi 서비스 인스턴스 수를 확장하여 HA( 고가용성 )를 제공합니다. 기본적으로 컨트롤러 수를 3개 이상으로 스케일링하면 HA 가 자동으로 활성화됩니다. OpenDaylight HA 아키텍처에 대한 자세한 내용은 High Availability and Clustering with OpenDaylight 를 참조하십시오.
그림 1.2. OpenDaylight 및 OpenStack#189 기반 아키텍처
1.3.2. Red Hat OpenStack Platform director에서 네트워크 격리 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat OpenStack Platform director는 개별 서비스를 사전 정의된 특정 네트워크 유형으로 구성할 수 있습니다. 이러한 네트워크 트래픽 유형은 다음과 같습니다.
| IPMI | 노드의 전원 관리 네트워크입니다. 언더클라우드를 설치하기 전에 이 네트워크를 설정해야 합니다. |
| 프로비저닝(ctlplane) | director는 이 네트워크 트래픽 유형을 사용하여 DHCP 및 PXE 부팅을 통해 새 노드를 배포하고 오버클라우드 베어 메탈 서버에 OpenStack Platform 설치를 오케스트레이션합니다. 언더클라우드를 설치하기 전에 네트워크를 설정해야 합니다. 또는 ironic에서 직접 운영 체제 이미지를 배포할 수 있습니다. 이 경우 PXE 부팅이 필요하지 않습니다. |
| 내부 API(internal_api) | 내부 API 네트워크는 API 통신, RPC 메시지 및 데이터베이스 통신을 사용하는 OpenStack 서비스 간 통신 및 로드 밸런서의 내부 통신에 사용됩니다. |
| 테넌트(테넌트) | Neutron은 각 테넌트에 VLAN (각 테넌트 네트워크가 네트워크 VLAN임) 또는 오버레이 터널을 사용하여 자체 네트워크를 제공합니다. 네트워크 트래픽은 각 테넌트 네트워크 내에서 격리됩니다. 터널을 사용하는 경우 여러 테넌트 네트워크가 충돌 없이 동일한 IP 주소 범위를 사용할 수 있습니다. |
GRE(Generic Routing Encapsulation) 및 VXLAN(Virtual eXtensible Local Area Network)은 코드베이스에서 사용할 수 있지만 VXLAN 은 OpenDaylight와 함께 사용하는 것이 권장되는 터널링 프로토콜입니다. VXLAN 은 RFC 7348 에 정의되어 있습니다. 이 문서의 나머지 부분에서는 터널링이 사용될 때마다 VXLAN 에 중점을 둡니다.
| 스토리지(스토리지) | 블록 스토리지, NFS, iSCSI 등. 이상적으로 이는 성능 최적화를 위해 완전히 별도의 스위치 패브릭으로 격리됩니다. |
| 스토리지 관리(storage_mgmt) | OpenStack Object Storage(swift)는 이 네트워크를 사용하여 복제본 노드 간 데이터 오브젝트를 동기화합니다. 프록시 서비스는 사용자 요청과 기본 스토리지 계층 간의 중간 인터페이스 역할을 합니다. 프록시는 들어오는 요청을 수신하고 요청된 데이터를 검색하는 데 필요한 복제본을 찾습니다. Ceph 백엔드를 사용하는 서비스는 스토리지 관리 네트워크를 통해, Ceph 와 직접 상호 작용하지 않고 프런트 엔드 서비스를 사용하기 때문입니다. 이 트래픽이 Ceph 에 직접 연결되므로 RBD 드라이버가 예외입니다. |
| 외부/공용 API | 이 API는 그래픽 시스템 관리, OpenStack 서비스의 공용 API인 OpenStack 대시보드(horizon)를 호스팅하고 인스턴스로 들어오는 트래픽에 대해 SNAT를 수행합니다. 외부 네트워크에서 프라이빗 IP 주소(RFC-1918에 따라)를 사용하는 경우 인터넷에서 들어오는 트래픽에 대해 추가 NAT를 수행해야 합니다. |
| 부동 IP | 테넌트 네트워크의 인스턴스에 할당된 유동 IP 주소와 고정 IP 주소 간의 일대일 IPv4 주소 매핑을 사용하여 들어오는 트래픽이 인스턴스에 연결할 수 있습니다. 일반적인 구성은 별도의 유지 관리 대신 외부 및 유동 IP 네트워크를 결합하는 것입니다. |
| 관리 | SSH 액세스, DNS 트래픽 및 NTP 트래픽과 같은 시스템 관리 기능에 대한 액세스를 제공합니다. 이 네트워크는 또한 컨트롤러가 아닌 노드의 게이트웨이 역할을 합니다. |
일반적인 Red Hat OpenStack Platform 설치에서는 종종 네트워크 유형의 수가 물리적 네트워크 연결 수를 초과합니다. 모든 네트워크를 적절한 호스트에 연결하기 위해 Overcloud에서 802.1q VLAN 태그를 사용하여 인터페이스당 두 개 이상의 네트워크를 제공할 수 있습니다. 대부분의 네트워크는 서브넷이 분리되어 있지만 일부는 인터넷 액세스 또는 인프라 네트워크 연결을 위해 라우팅을 제공하기 위해 계층 3 게이트웨이가 필요합니다.
OpenDaylight의 경우 관련 네트워크에는 ServiceNetMap 내부의 각 네트워크에 매핑되는 내부 API 및 테넌트 서비스가 포함됩니다. 기본적으로 ServiceNetMap 은 OpenDaylightApi 네트워크를 내부 API 네트워크에 매핑합니다. 이 구성은 OVS 에 대한 southbound 트래픽뿐만 아니라 northbound 트래픽을 내부 API 네트워크로 격리한다는 것을 의미합니다.
OpenDaylight가 분산 라우팅 아키텍처를 사용하므로 각 컴퓨팅 노드가 유동 IP 네트워크에 연결되어 있어야 합니다. 기본적으로 Red Hat OpenStack Platform director는 외부 네트워크가 OVS 브리지 br-ex 에 매핑된 물리적 neutron 네트워크 datacentre 에서 실행됩니다. 따라서 컴퓨팅 노드 NIC 템플릿의 기본 구성에 br-ex 브릿지를 포함해야 합니다.
그림 1.3. OpenDaylight 및 OpenStack#189 네트워크 격리 예
1.3.3. 네트워크 및 방화벽 구성 링크 복사링크가 클립보드에 복사되었습니다!
제한적인 방화벽이 있는 경우와 같은 일부 배포에서는 OpenStack 및 OpenDaylight 서비스 트래픽을 활성화하려면 방화벽을 수동으로 구성해야 할 수 있습니다.
기본적으로 OpenDaylight Northbound는 8080 포트를 사용합니다. 8080 포트를 사용하는 swift 서비스와 충돌하지 않도록 Red Hat OpenStack Platform director와 함께 설치할 때 OpenDaylight 포트가 8081 로 설정됩니다. Red Hat OpenDaylight 솔루션의 Southbound는 일반적으로 OVS 인스턴스가 연결되는 포트 6640 및 6653 에서 수신 대기하도록 구성됩니다.
OpenStack에서 각 서비스에는 일반적으로 고유한 VIP(가상 IP 주소)가 있으며 OpenDaylight는 동일한 방식으로 작동합니다. HAProxy 는 8081 포트 를 공용으로 열고 OpenStack에 이미 있는 플레인 VIP를 제어하도록 구성되어 있습니다. VIP 및 포트가 ML2 플러그인에 표시되고 neutron은 모든 통신을 전송합니다. OVS 인스턴스는 Southbound에 대해 OpenDaylight가 실행되고 있는 노드의 물리적 IP에 직접 연결합니다.
| 서비스 | 프로토콜 | 기본 포트 | 네트워크 |
|---|---|---|---|
| OpenStack Neutron API | TCP | 9696 | 내부 API |
| OpenStack Neutron API(SSL) | TCP | 13696 | 내부 API |
| OpenDaylight Northbound | TCP | 8081 | 내부 API |
| OpenDaylight Southbound: OVSDB | TCP | 6640 | 내부 API |
| OpenDaylight Southbound: OpenFlow | TCP | 6653 | 내부 API |
| OpenDaylight High Availability | TCP | 2550 | 내부 API |
| VXLAN | UDP | 4789 | 테넌트 |
표 1: 네트워크 및 방화벽 구성
이 섹션에서는 OpenDaylight 통합과 관련된 서비스 및 프로토콜에 중점을 두고 완전한 것은 아닙니다. Red Hat OpenStack에서 실행되는 서비스에 필요한 전체 네트워크 포트 목록은 Red Hat OpenStack Platform용 방화벽 규칙 을 참조하십시오.
2장. OpenDaylight를 실행하려면 어떻게 해야 합니까? 링크 복사링크가 클립보드에 복사되었습니다!
다음 섹션에서는 OpenDaylight를 사용한 오버클라우드 배포 요구 사항에 대해 설명합니다. Red Hat OpenDaylight를 올바르게 설치하고 실행할 수 있는 충분한 컴퓨터 리소스가 있어야 합니다. 다음 정보를 사용하여 최소 요구 사항을 파악합니다.
2.1. 컴퓨팅 노드 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
컴퓨팅 노드는 가상 머신 인스턴스가 시작된 후 이를 실행하는 역할을 합니다. 모든 컴퓨팅 노드는 하드웨어 가상화를 지원해야 합니다. 또한 호스팅하는 가상 머신 인스턴스의 요구 사항을 지원하기에 충분한 메모리 및 디스크 공간이 있어야 합니다.
| 프로세서 | Intel 64 또는 AMD64 CPU 확장 기능을 지원하고 AMD-V 또는 Intel VT 하드웨어 가상화 확장 기능이 활성화된 64비트 프로세서. 이 프로세서에 최소 4개의 코어가 있는 것이 좋습니다. |
| 메모리 | 최소 6GB의 RAM. 가상 머신 인스턴스에서 사용하려는 메모리 크기에 따라 이 요구 사항에 RAM을 추가합니다. |
| 디스크 공간 | 최소 40GB의 사용 가능한 디스크 공간 |
| 네트워크 인터페이스 카드 | 최소 1개의 1Gbps 네트워크 인터페이스 카드가 필요합니다. 프로덕션 환경에서 NIC(네트워크 인터페이스 카드)를 두 개 이상 사용하는 것이 좋습니다. 본딩된 인터페이스나 태그된 VLAN 트래픽 위임에는 추가 네트워크 인터페이스 카드를 사용하십시오. NIC에 대한 자세한 내용은 Tested NIC를 참조하십시오. |
| 전원 관리 | 각 컨트롤러 노드에는 서버의 마더보드에서 IPMI(Intelligent Platform Management Interface) 기능과 같은 지원되는 전원 관리 인터페이스가 필요합니다. |
2.2. 컨트롤러 노드 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
컨트롤러 노드는 Red Hat OpenStack Platform 환경에서 horizon 대시보드, 백엔드 데이터베이스 서버, keystone 인증, 고가용성 서비스와 같은 핵심 서비스를 호스팅합니다.
| 프로세서 | Intel 64 또는 AMD64 CPU 확장을 지원하는 64비트 프로세서입니다. |
| 메모리 | 최소 메모리 용량은 20GB입니다. 그러나 권장 메모리 양은 CPU 코어 수에 따라 다릅니다. 다음 계산을 지침으로 사용하십시오. 컨트롤러의 최소 RAM 계산: 코어당 1.5GB 메모리를 사용합니다. 예를 들어 코어가 48개인 머신에는 72GB RAM이 있어야 합니다. 컨트롤러의 권장 RAM 계산: 코어당 3GB의 메모리를 사용합니다. 예를 들어 코어가 48개인 머신에는 144GB RAM이 있어야 합니다. 메모리 요구 사항 측정에 대한 자세한 내용은 Red Hat 고객 포털의 고가용성 컨트롤러에 대한 Red Hat OpenStack Platform 하드웨어 요구 사항 을 참조하십시오. |
| 디스크 공간 | 최소 40GB의 사용 가능한 디스크 공간 |
| 네트워크 인터페이스 카드 | 최소 2개의 1GB의 네트워크 인터페이스 카드가 필요합니다. 본딩된 인터페이스나 태그된 VLAN 트래픽 위임에는 추가 네트워크 인터페이스 카드를 사용하십시오. |
| 전원 관리 | 각 컨트롤러 노드에는 서버의 마더보드에서 IPMI(Intelligent Platform Management Interface) 기능과 같은 지원되는 전원 관리 인터페이스가 필요합니다. |
3장. 오버클라우드에 OpenDaylight 설치 링크 복사링크가 클립보드에 복사되었습니다!
이 문서에서는 OpenDaylight 설치에만 중점을 둡니다. OpenDaylight를 배포하기 전에 작동 중인 언더클라우드 환경이 있고 오버클라우드 노드가 실제 네트워크에 연결되어 있는지 확인해야 합니다.
언더클라우드 및 오버클라우드 배포에 필요한 절차 를 설명하는 Director 설치 및 사용 가이드 의 CLI 툴을 사용하여 Undercloud 설치 및 기본 Overcloud 요구 사항 설치를 참조하십시오.
Red Hat OpenStack 플랫폼에 OpenDaylight를 설치하는 방법은 여러 가지가 있습니다. 다음 장에서는 OpenDaylight의 가장 유용한 시나리오와 설치 방법을 소개합니다.
3.1. 기본 구성 이해 및 설정 사용자 정의 링크 복사링크가 클립보드에 복사되었습니다!
OpenDaylight를 설치하는 데 권장되는 방법은 기본 환경 파일 neutron-opendaylight.yaml 을 사용하여 언더클라우드에서 배포 명령에 인수로 전달하는 것입니다. 그러면 OpenDaylight의 기본 설치가 배포됩니다.
기타 OpenDaylight 설치 및 구성 시나리오는 이 설치 방법을 기반으로 합니다. 배포 명령에 특정 환경 파일을 제공하여 다양한 시나리오를 사용하여 OpenDaylight를 배포할 수 있습니다.
3.1.1. 기본 환경 파일 이해 링크 복사링크가 클립보드에 복사되었습니다!
기본 환경 파일은 /usr/share/openstack-tripleo-heat-templates/environments/services 디렉터리의 neutron-opendaylight.yaml 입니다. 이 환경 파일은 OpenDaylight가 지원하는 서비스를 활성화하거나 비활성화합니다. 환경 파일은 배포 중에 director가 설정하는 필수 매개변수도 정의합니다.
다음 파일은 Docker 기반 배포에 사용할 수 있는 neutron-opendaylight.yaml 파일의 예입니다.
Red Hat OpenStack Platform director는 resource_registry 를 사용하여 배포에 대한 리소스를 해당 리소스 정의 yaml 파일에 매핑합니다. 서비스는 매핑할 수 있는 하나의 유형의 리소스입니다. 특정 서비스를 비활성화하려면 OS::Heat::None 값을 설정합니다. 기본 파일에서 OpenDaylightApi 및 OpenDaylightOvs 서비스는 활성화되어 있지만 OpenDaylight가 기능을 상속하면 기본 Neutron 에이전트가 명시적으로 비활성화됩니다.
heat 매개변수를 사용하여 director로 배포 설정을 구성할 수 있습니다. 환경 파일의 parameter_defaults 섹션을 사용하여 기본값을 재정의할 수 있습니다.
이 예에서 NeutronEnableForceMetadata,NeutronMechanismDrivers 및 NeutronServicePlugins 매개 변수는 OpenDaylight를 사용하도록 설정됩니다.
기타 서비스 및 해당 구성 옵션 목록은 이 가이드의 뒷부분에 제공되어 있습니다.
3.1.2. OpenDaylight API 서비스 구성 링크 복사링크가 클립보드에 복사되었습니다!
필요에 맞게 /usr/share/openstack-tripleo-heat-templates/puppet/services/opendaylight-api.yaml 파일의 기본값을 변경할 수 있습니다. 이 파일의 설정을 직접 덮어쓰지 마십시오. 이 파일을 중복하고 백업 솔루션으로 원본을 유지합니다. 중복만 수정하고 중복을 배포 명령에 전달합니다.
후자의 환경 파일의 매개변수는 이전 환경 파일에서 설정된 변수를 재정의합니다. 실수로 매개 변수를 덮어쓰지 않도록 환경 파일의 순서에 주의하십시오.
3.1.2.1. 구성 가능한 옵션 링크 복사링크가 클립보드에 복사되었습니다!
OpenDaylight API 서비스 를 구성할 때 다음과 같은 몇 가지 매개변수를 설정할 수 있습니다.
|
|
Northbound 통신에 사용되는 포트입니다. 기본값은 |
|
|
OpenDaylight의 로그인 사용자 이름입니다. 기본값은 |
|
|
OpenDaylight의 로그인 암호입니다. 기본값은 |
|
|
OpenDaylight가 DHCP 서비스로 작동하도록 활성화합니다. 기본값은 |
|
|
OpenDaylight에서 부팅할 쉼표로 구분된 기능 목록입니다. 기본값은 |
|
|
REST 액세스에 사용되는 L7 프로토콜입니다. 기본값은 |
|
|
OpenDaylight 리포지토리를 관리할지 여부를 정의합니다. 기본값은 |
|
|
OpenDaylight에서 사용할 SNAT 메커니즘입니다. |
|
|
OpenDaylight를 위한 로깅 메커니즘입니다. |
|
|
OpenDaylight TLS 키 저장소의 암호입니다. 기본값은 |
|
|
내부 네트워크에서 TLS를 활성화하거나 비활성화합니다. |
|
|
내부 네트워크에서 서비스에 TLS를 활성화하는 경우 |
TLS를 사용하여 배포하는 방법에 대한 자세한 내용은 Advanced Overcloud Customization Guide 를 참조하십시오.
3.1.3. OpenDaylight OVS 서비스 구성 링크 복사링크가 클립보드에 복사되었습니다!
필요에 맞게 /usr/share/openstack-tripleo-heat-templates/puppet/services/opendaylight-ovs.yaml 파일의 기본값을 변경할 수 있습니다. 이 파일의 설정을 직접 덮어쓰지 마십시오. 이 파일을 중복하고 백업 솔루션으로 원본을 유지합니다. 중복만 수정하고 중복을 배포 명령에 전달합니다.
후자의 환경 파일의 매개변수는 이전 환경 파일에서 설정된 변수를 재정의합니다. 실수로 매개 변수를 덮어쓰지 않도록 환경 파일의 순서에 주의하십시오.
3.1.3.1. 구성 가능한 옵션 링크 복사링크가 클립보드에 복사되었습니다!
OpenDaylight OVS 서비스 를 구성할 때 다음과 같은 몇 가지 매개변수를 설정할 수 있습니다.
|
|
OpenDaylight와 Northbound 통신에 사용되는 포트입니다. 기본값은 |
|
|
REST 액세스에 사용되는 계층 7 프로토콜입니다. 기본값은 |
|
|
OVS가 연결되기 전에 OpenDaylight가 완전히 up인지 확인하는 URL입니다. 기본값은 |
|
|
논리 네트워크와 물리적 인터페이스 간의 쉼표로 구분된 매핑 목록입니다. 이 설정은 VLAN 배포에 필요합니다. 기본값은 |
|
|
OpenDaylight OVS 서비스의 사용자 지정 사용자 이름입니다. 기본값은 |
|
|
OpenDaylight OVS 서비스의 사용자 지정 암호입니다. 기본값은 |
|
|
이 OVS 호스트에 대해 허용된 테넌트 네트워크 유형을 정의합니다. 호스트 또는 역할에 따라 nova 인스턴스와 네트워크가 예약된 호스트를 제한할 수 있습니다. 기본값은 |
|
|
OVS에서 DPDK를 활성화하거나 비활성화합니다. 기본값은 |
|
|
vhostuser 포트 생성이 있는 OVS 모드입니다. 클라이언트 모드에서 하이퍼바이저는 vhostuser 소켓을 생성합니다. 서버 모드에서 OVS는 이를 생성합니다. 기본값은 |
|
|
vhostuser 소켓에 사용할 디렉터리입니다. 기본값은 |
|
|
OVS Hardware Offload를 활성화하거나 비활성화합니다. |
|
|
내부 네트워크에서 TLS를 활성화하거나 비활성화합니다. |
|
|
내부 네트워크에서 서비스에 TLS를 활성화하는 경우 |
|
|
OpenDaylight 업데이트 수준입니다. |
|
|
vhost-user 소켓 디렉터리 그룹입니다. vhostuser가 기본 |
|
|
vhost-user 소켓 디렉터리 사용자 이름입니다. vhostuser가 기본 |
3.1.4. OpenDaylight에서 neutron 메타데이터 서비스 사용 링크 복사링크가 클립보드에 복사되었습니다!
OpenStack Compute 서비스를 사용하면 가상 머신에서 특수 주소 169.254.169.254 에 웹 요청을 수행하여 연결된 메타데이터를 쿼리할 수 있습니다. OpenStack Networking은 요청이 격리된 또는 IP 주소가 겹치는 여러 네트워크에서 발생하는 경우에도 nova-api 에 대한 요청을 프록시합니다.
메타데이터 서비스는 neutron L3 에이전트 라우터를 사용하여 메타데이터 요청 또는 DHCP 에이전트 인스턴스를 제공합니다. 계층 3 라우팅 플러그인이 활성화된 OpenDaylight를 배포하면 neutron L3 에이전트가 비활성화됩니다. 따라서 테넌트 네트워크에 라우터가 있는 경우에도 DHCP 인스턴스를 통해 전달하도록 메타데이터를 구성해야 합니다. 이 기능은 기본 환경 파일 neutron-opendaylight.yaml 에서 활성화되어 있습니다. 이를 비활성화하려면 NeutronEnableForceMetadata 를 false 로 설정합니다.
VM 인스턴스에는 DHCP 옵션 121 을 사용하여 169.254.169.254/32 의 정적 호스트 경로가 설치되어 있습니다. 이 정적 경로가 배치되면 169.254.169.254:80 에 대한 메타데이터 요청이 DHCP 네트워크 네임스페이스의 메타데이터 이름 서버 프록시로 이동합니다. 그런 다음 네임스페이스 프록시는 인스턴스의 IP와 함께 HTTP 헤더를 요청에 추가하고 Unix 도메인 소켓을 통해 메타데이터 에이전트에 연결합니다. 메타데이터 에이전트는 소스 IP 및 네트워크 ID에 해당하는 인스턴스 ID에 대해 neutron을 쿼리하고 nova Metadata 서비스에 프록시합니다. 테넌트 간에 격리를 유지하고 중복되는 IP 지원을 허용하려면 추가 HTTP 헤더가 필요합니다.
3.1.5. 네트워크 구성 및 NIC 템플릿 이해 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat OpenStack Platform director에서 물리적 neutron 네트워크 데이터 센터는 기본적으로 br-ex 라는 OVS 브릿지에 매핑됩니다. 이는 OpenDaylight 통합과 일관되게 동일합니다. 기본 OpenDaylightProviderMappings 를 사용하고 flat 또는 VLAN _External 네트워크를 생성하는 경우 컴퓨팅 노드의 NIC 템플릿에서 OVS br-ex 브릿지를 구성해야 합니다. 레이어 3 플러그인은 이러한 노드에 분산 라우팅을 사용하므로 더 이상 컨트롤러 역할 NIC 템플릿에서 br-ex를 구성할 필요가 없습니다.
br-ex 브리지는 네트워크 격리의 모든 네트워크에 매핑할 수 있지만 일반적으로 예제에 표시된 대로 외부 네트워크에 매핑됩니다.
DPDK를 사용하여 일반적으로 br-phy 라는 다른 OVS 브리지를 만들고 ovs-dpdk-port를 제공해야 합니다. 브리지의 IP 주소는 VXLAN 오버레이 네트워크 터널용으로 구성됩니다.
네트워크 분리를 사용하는 경우 컴퓨팅 노드의 이 브릿지에 IP 주소 또는 기본 경로를 배치할 필요가 없습니다.
또는 br-ex 브리지를 사용하지 않고 외부 네트워크 액세스를 구성할 수도 있습니다. 이 방법을 사용하려면 오버클라우드 컴퓨팅 노드의 인터페이스 이름을 사전에 알고 있어야 합니다. 예를 들어 eth3 이 컴퓨팅 노드에서 세 번째 인터페이스의 결정적인 이름인 경우 이를 사용하여 컴퓨팅 노드의 NIC 템플릿에서 인터페이스를 지정할 수 있습니다.
- type: interface name: eth3 use_dhcp: false
-
type: interface
name: eth3
use_dhcp: false
3.2. OpenDaylight의 기본 설치 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션에서는 표준 환경 파일을 사용하여 OpenDaylight를 배포하는 방법을 설명합니다.
3.2.1. 오버클라우드에 대해 OpenDaylight 환경 파일 준비 링크 복사링크가 클립보드에 복사되었습니다!
시작하기 전에
- 언더클라우드를 설치합니다. 자세한 내용은 언더클라우드 설치를 참조하십시오.
- 필요한 경우 오버클라우드 및 OpenDaylight 설치 중에 사용하려는 컨테이너 이미지로 로컬 레지스트리를 생성합니다. 자세 한 내용은 Director 설치 및 사용 가이드의 컨테이너 이미지 소스 구성 을 참조하십시오.
절차
언더클라우드에 로그인하여 관리자 자격 증명을 로드합니다.
source ~/stackrc
$ source ~/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow OpenStack 및 OpenDaylight 설치에 필요한 Docker 컨테이너 이미지에 대한 참조가 포함된 Docker 레지스트리 파일
odl-images.yaml을 생성합니다.openstack overcloud container image prepare -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight.yaml --output-env-file /home/stack/templates/odl-images.yaml
$ openstack overcloud container image prepare -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight.yaml --output-env-file /home/stack/templates/odl-images.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
이제 오버클라우드를 배포할 환경을 준비하고 3.2.2절. “OpenDaylight를 사용하여 오버클라우드 설치” 에 설명된 설치를 시작할 준비가 되었습니다.
더 많은 정보
openstack overcloud image prepare 명령은 오버클라우드 및 OpenDaylight를 설치할 컨테이너 이미지 환경 파일을 준비합니다. 이 명령은 다음 옵션을 사용합니다.
- -e
- OpenDaylight 및 OVS와 같이 해당 환경에 필요한 특정 컨테이너 이미지를 추가하는 서비스 환경 파일을 지정합니다.
- --env-file
- 설치에 사용할 컨테이너 이미지 목록이 포함된 새 컨테이너 이미지 환경 파일을 생성합니다.
- --pull-source
- Docker 컨테이너 레지스트리의 위치 설정
- --namespace
- Docker 컨테이너의 버전을 설정합니다.
- --prefix
- 이미지 이름에 접두사 추가
- --suffix
- 이미지 이름에 접미사 추가
- --tag
- 이미지 릴리스를 정의합니다.
3.2.2. OpenDaylight를 사용하여 오버클라우드 설치 링크 복사링크가 클립보드에 복사되었습니다!
시작하기 전에
- 오버클라우드 절차의 OpenDaylight 환경 파일 을 수행하여 배포에 필요한 환경 파일을 생성합니다.
절차
언더클라우드에 로그인하여 관리자 자격 증명을 로드합니다.
source ~/stackrc
$ source ~/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이전에 생성된 환경 파일을 사용하여 오버클라우드를 배포합니다.
openstack overcloud deploy --templates /usr/share/openstack-tripleo-heat-templates \ -e <other environment files> -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight.yaml \ -e /home/stack/templates/odl-images.yaml
$ openstack overcloud deploy --templates /usr/share/openstack-tripleo-heat-templates \ -e <other environment files> -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight.yaml \ -e /home/stack/templates/odl-images.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
배포 명령에 있는 환경 파일은 명령에 앞서 포함하는 환경 파일을 덮어씁니다. 실수로 매개 변수를 덮어쓰지 않도록 포함하는 환경 파일의 순서에 주의하십시오.
변경하려는 매개변수만 설정하고 기본 환경 파일과 결합하는 최소 환경 파일을 생성하여 일부 매개변수를 재정의할 수 있습니다.
더 많은 정보
이 절차의 openstack overcloud deploy 명령에서는 다음 옵션을 사용합니다.
- --templates
- heat 템플릿 디렉터리의 경로를 정의합니다.
- -e
- 환경 파일을 지정합니다.
3.3. 사용자 지정 역할에 OpenDaylight 설치 링크 복사링크가 클립보드에 복사되었습니다!
Custom 역할에 OpenDaylight를 설치하면 컨트롤러 노드와 다른 지정된 OpenDaylight 노드에서 실행되는 분리된 OpenDaylightApi 서비스가 생성됩니다.
OpenDaylight에 Custom 역할을 사용하려면 노드 레이아웃 및 기능 구성이 포함된 역할 파일을 만들어야 합니다.
3.3.1. 기본 역할에 따라 역할 파일 사용자 지정 링크 복사링크가 클립보드에 복사되었습니다!
사용자 정의 서비스 목록을 실행하는 각 역할에 대한 사용자 정의 역할 목록을 사용하여 OpenStack을 배포할 수 있습니다. 역할은 개별 서비스 또는 구성을 포함하는 노드 그룹입니다. 예를 들어 nova API 서비스가 포함된 Controller 역할을 생성할 수 있습니다. openstack-tripleo-heat-templates 에서 예제 역할을 볼 수 있습니다.
이러한 역할을 사용하여 오버클라우드 노드에 원하는 역할이 포함된 roles_data.yaml 파일을 생성합니다. 디렉터리에 개별 파일을 생성하여 사용자 지정 역할을 생성하고 이를 사용하여 새 roles_data.yaml 을 생성할 수도 있습니다.
특정 OpenStack 역할만 설치하는 사용자 지정 환경 파일을 생성하려면 다음 단계를 완료합니다.
절차
admin 자격 증명을 로드합니다.
source ~/stackrc
$ source ~/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow 사용자 지정
roles_data.yaml파일을 생성하는 데 사용할 수 있는 기본 역할을 나열합니다.openstack overcloud role list
$ openstack overcloud role listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이러한 역할을 모두 사용하려면 다음 명령을 실행하여
roles_data.yaml파일을 생성합니다.openstack overcloud roles generate -o roles_data.yaml
$ openstack overcloud roles generate -o roles_data.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 일부 역할만 포함하도록 역할 파일을 사용자 지정하려면 이전 단계의 명령에 인수로 역할 이름을 전달할 수 있습니다. 예를 들어 컨트롤러,Compute 및 Telemetry 역할을 사용하여
roles_data.yaml파일을 생성하려면 다음 명령을 실행합니다.openstack overcloud roles generate - roles_data.yaml Controller Compute Telemetry
$ openstack overcloud roles generate - roles_data.yaml Controller Compute TelemetryCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3.2. OpenDaylight를 위한 사용자 정의 역할 생성 링크 복사링크가 클립보드에 복사되었습니다!
사용자 지정 역할을 생성하려면 역할 파일 디렉터리에 새 역할 파일을 생성하고 새 roles_data.yaml 파일을 생성합니다. 생성하는 각 사용자 지정 역할에 대해 새 역할 파일을 생성해야 합니다. 각 사용자 지정 역할 파일에는 특정 역할에 대한 데이터만 포함해야 하며 사용자 지정 역할 파일 이름은 역할 이름과 일치해야 합니다.
최소한 파일은 다음 매개변수를 정의해야 합니다.
name
:역할의 이름을 정의합니다. 이름은 항상 비어 있지 않은 고유 문자열이어야 합니다.- Name: Custom_role
- Name: Custom_roleCopy to Clipboard Copied! Toggle word wrap Toggle overflow ServicesDefault:이 역할에 사용된 서비스를 나열합니다. 사용된 서비스가 없는 경우 변수는 비어 있을 수 있습니다. 예제 형식은 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
필수 매개변수 외에도 추가 설정을 정의할 수도 있습니다.
CountDefault:기본 노드 수를 정의합니다.CountDefault:가 비어 있으면 기본값은 0입니다.CountDefault: 1
CountDefault: 1Copy to Clipboard Copied! Toggle word wrap Toggle overflow HostnameFormatDefault:호스트 이름에 대한 형식 문자열을 정의합니다. 값은 선택 사항입니다.HostnameFormatDefault: '%stackname%-computeovsdpdk-%index%'
HostnameFormatDefault: '%stackname%-computeovsdpdk-%index%'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 설명:역할에 대한 정보를 설명하고 추가합니다.Description: Compute OvS DPDK RoleDescription: Compute OvS DPDK RoleCopy to Clipboard Copied! Toggle word wrap Toggle overflow
절차
기본 역할 파일을 새 디렉터리에 복사하고 원본 파일을 백업으로 유지합니다.
mkdir ~/roles cp /usr/share/openstack-tripleo-heat-templates/roles/* ~/roles
$ mkdir ~/roles $ cp /usr/share/openstack-tripleo-heat-templates/roles/* ~/rolesCopy to Clipboard Copied! Toggle word wrap Toggle overflow ~/roles의Controller.yaml파일에서 기본 Controller 역할을 수정하고 파일에서OpenDaylightApi행을 제거하여 컨트롤러 노드에서 OpenDaylightAPI 서비스를 비활성화합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow ~/roles디렉터리에 새OpenDaylight.yaml파일을 생성하고 OpenDaylight 역할 설명을 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 파일을 저장합니다.
사용자 지정 역할에서 OpenDaylight를 사용하여 OpenStack 오버클라우드를 배포할 때 사용할 새 역할 파일을 생성합니다.
openstack overcloud roles generate --roles-path ~/roles -o ~/roles_data.yaml Controller Compute OpenDaylight
$ openstack overcloud roles generate --roles-path ~/roles -o ~/roles_data.yaml Controller Compute OpenDaylightCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3.3. 사용자 정의 역할에 OpenDaylight를 사용하여 OverCloud 설치 링크 복사링크가 클립보드에 복사되었습니다!
시작하기 전에
- 언더클라우드를 설치합니다. 자세한 내용은 언더클라우드 설치를 참조하십시오.
- 오버클라우드 컨테이너 이미지에 대한 링크로 환경 파일을 생성합니다. 자세한 내용은 OpenDaylight를 사용하여 오버클라우드 설치 준비 를 참조하십시오.
- 사용자 지정 역할에 OpenDaylight를 구성하도록 역할 파일을 준비합니다. 자세한 내용은 OpenDaylight를 위한 사용자 지정 역할 만들기를 참조하십시오.
절차
사용자 지정 역할을 생성합니다. 환경 파일에서 다음 매개변수 값을 설정합니다.
- OvercloudOpenDaylightFlavor: opendaylight - OvercloudOpenDaylightCount: 3- OvercloudOpenDaylightFlavor: opendaylight - OvercloudOpenDaylightCount: 3Copy to Clipboard Copied! Toggle word wrap Toggle overflow 자세 한 내용은 roles_data 파일 생성을 참조하십시오.
기본 역할 정의를 재정의하려면 -r 인수와 함께 배포 명령을 실행합니다. 이 옵션은 사용자 지정 역할이 포함된
roles_data.yaml파일을 사용하도록 배포 명령에 지시합니다. 이전 단계에서 생성한odl-composable.yaml환경 파일을 이 배포 명령에 전달합니다. 이 예제에는 총 3개의 ironic 노드가 있습니다. 사용자 정의 OpenDaylight 역할을 위해 하나의 ironic 노드가 예약되어 있습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
배포 명령에 있는 환경 파일은 명령에 앞서 포함하는 환경 파일을 덮어씁니다. 실수로 매개 변수를 덮어쓰지 않도록 포함하는 환경 파일의 순서에 주의하십시오.
변경하려는 매개변수만 설정하고 기본 환경 파일과 결합하는 최소 환경 파일을 생성하여 일부 매개변수를 재정의할 수 있습니다.
더 많은 정보
-r옵션은 설치 시 역할 정의를 재정의합니다.-r <roles_data>.yaml
-r <roles_data>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 사용자 정의 역할에는 설치 중에 추가 ironic 노드가 필요합니다.
- 사용자 지정 역할에 대한 rhosp13 composable 역할의 노드 카운터를 재정의하려면 다음 예의 구문을 사용하십시오. <role-name>Count: <value> 역할 이름 업데이트 role_data.yaml 파일에서 정확한 이름 세부 정보로 업데이트합니다.
3.3.4. 사용자 지정 역할에서 OpenDaylight 설치 확인 링크 복사링크가 클립보드에 복사되었습니다!
시작하기 전에
- 사용자 지정 역할에 OpenDaylight를 사용하여 Overcloud를 설치합니다. 자세한 내용은 사용자 지정 역할에 OpenDaylight를 사용하여 Overcloud 설치 를 참조하십시오.
절차
기존 인스턴스를 나열합니다.
openstack server list
$ openstack server listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 새 OpenDaylight 역할이 인스턴스로 전용인지 확인합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4. SR-IOV 지원을 사용하여 OpenDaylight 설치 링크 복사링크가 클립보드에 복사되었습니다!
SR-IOV( Single Root Input/Output Virtualization )를 지원하는 컴퓨팅 노드와 함께 OpenDaylight를 배포할 수 있습니다. 이 배포에서 컴퓨팅 노드는 전용 SR-IOV 노드로 작동해야 하며 OVS를 기반으로 하는 nova 인스턴스와 혼합해서는 안 됩니다. 하나의 OpenDaylight 배포에 OVS 및 SR-IOV 컴퓨팅 노드를 둘 다 배포할 수 있습니다.
이 시나리오에서는 사용자 정의 SR-IOV Compute 역할을 사용하여 이러한 종류의 배포를 수행합니다.
SR-IOV 배포에서는 neutron SR-IOV 에이전트를 사용하여 VF(가상 기능)를 구성해야 합니다. 그런 다음 이러한 함수가 배포 시 직접 Compute 인스턴스에 전달되고 네트워크 포트로 사용됩니다. VF는 컴퓨팅 노드의 호스트 NIC에서 파생되므로 배포를 시작하기 전에 호스트 인터페이스에 대한 일부 정보가 필요합니다.
3.4.1. SR-IOV 컴퓨팅 역할 준비 링크 복사링크가 클립보드에 복사되었습니다!
OpenDaylight In Custom Role 에 표시된 것과 동일한 방법론을 따라 SR-IOV 기반 인스턴스를 생성할 수 있도록 SR-IOV 컴퓨팅 노드에 대한 사용자 정의 역할을 생성해야 기본 Compute 역할은 OVS 기반 Nova 인스턴스를 제공합니다.
절차
기본 역할 파일을 새 디렉터리에 복사하고 원본 파일을 백업으로 유지합니다.
mkdir ~/roles cp /usr/share/openstack-tripleo-heat-templates/roles/* ~/roles
$ mkdir ~/roles $ cp /usr/share/openstack-tripleo-heat-templates/roles/* ~/rolesCopy to Clipboard Copied! Toggle word wrap Toggle overflow ~/roles디렉터리에 새ComputeSriov.yaml파일을 생성하고 다음 역할 설명을 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 파일을 저장합니다.
기본 Compute 역할에서
NeutronSriovAgent및NeutronSriovHostConfig서비스를 제거하고 해당 정보를 roles_data.yaml에 저장합니다.- OS::TripleO::Services::NeutronSriovHostConfig - OS::TripleO::Services::NeutronSriovAgent- OS::TripleO::Services::NeutronSriovHostConfig - OS::TripleO::Services::NeutronSriovAgentCopy to Clipboard Copied! Toggle word wrap Toggle overflow OpenDaylight Compute SR-IOV 지원을 사용하여 OpenStack 오버클라우드를 배포하는 데 사용할 새 역할 파일을 생성합니다.
openstack overcloud roles generate --roles-path ~/roles -o ~/roles_data.yaml Controller Compute ComputeSriov
$ openstack overcloud roles generate --roles-path ~/roles -o ~/roles_data.yaml Controller Compute ComputeSriovCopy to Clipboard Copied! Toggle word wrap Toggle overflow 로컬 레지스트리를 생성합니다.
openstack overcloud container image prepare --namespace=192.168.24.1:8787/rhosp13 --prefix=openstack- --tag=2018-05-07.2 -e /home/stack/templates/environments/services-docker/neutron-opendaylight.yaml -e /home/stack/templates/environments/services-docker/neutron-opendaylight-sriov.yaml --output-env-file=/home/stack/templates/overcloud_images.yaml --roles-file /home/stack/templates/roles_data.yaml
openstack overcloud container image prepare --namespace=192.168.24.1:8787/rhosp13 --prefix=openstack- --tag=2018-05-07.2 -e /home/stack/templates/environments/services-docker/neutron-opendaylight.yaml -e /home/stack/templates/environments/services-docker/neutron-opendaylight-sriov.yaml --output-env-file=/home/stack/templates/overcloud_images.yaml --roles-file /home/stack/templates/roles_data.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4.2. SR-IOV 에이전트 서비스 구성 링크 복사링크가 클립보드에 복사되었습니다!
SR-IOV 지원을 사용하여 OpenDaylight를 배포하려면 neutron-opendaylight.yaml 파일의 기본 매개변수를 재정의해야 합니다. /usr/share/openstack-tripleo-heat-templates 및 neutron-opendaylight.yaml 환경 파일에 있는 표준 SR-IOV 환경 파일을 사용할 수 있습니다. 그러나 원본 파일을 편집하지 않는 것이 좋습니다. 대신 원래 환경 파일을 복사하고 중복 파일에서 매개 변수를 수정합니다.
또는 변경하려는 매개변수만 제공하는 새 환경 파일을 만들고 배포에 두 파일을 모두 사용할 수도 있습니다. 사용자 지정 OpenDaylight를 배포하려면 두 파일을 모두 배포 명령에 전달합니다. 최신 환경 파일은 이전 설정을 재정의하므로 배포 명령에 올바른 순서로 포함해야 합니다. 올바른 순서는 먼저 neutron-opendaylight.yaml 이고, 그 다음 neutron-opendaylight-sriov.yaml.
기본 설정으로 OpenDaylight 및 SR-IOV를 배포하려면 Red Hat에서 제공하는 neutron-opendaylight-sriov.yaml 을 사용할 수 있습니다. 매개변수를 변경하거나 추가해야 하는 경우 기본 SR-IOV 환경 파일을 복사한 후 새로 생성된 파일을 편집합니다.
다음은 사용자 정의된 neutron-opendaylight-sriov.yaml 파일의 설명적인 예입니다.
더 많은 정보
neutron-opendaylight-sriov.yaml 파일에서 다음 옵션을 구성할 수 있습니다. 표에서는 개별 옵션을 설명하고 SR-IOV 기능을 활성화하는 데 필요한 설정을 표시합니다.
|
|
SR-IOV에 PCI 패스스루를 사용할 수 있습니다. 환경 파일에서 주석 처리를 제거하고 |
|
|
Nova 기본 필터에 대한 PCI 패스스루 필터 지정을 활성화합니다. |
|
| 논리적 neutron 네트워크를 호스트 네트워크 인터페이스에 매핑합니다. neutron이 가상 네트워크를 물리적 포트에 바인딩할 수 있도록 지정해야 합니다. |
|
|
호스트 네트워크 인터페이스에 생성할 VF 수입니다. 구문: < |
|
| nova에서 허용된 PCI 장치의 화이트리스트를 목록 형식으로 설정합니다. 예를 들면 다음과 같습니다. NovaPCIPassthrough:
- vendor_id: "8086"
product_id: "154c"
address: "0000:05:00.0"
physical_network: "datacentre"
또한 특정 하드웨어 속성 대신 논리적 장치 이름을 사용할 수도 있습니다. NovaPCIPassthrough:
- devname: "ens20f2"
physical_network: "datacentre"
|
3.4.3. SR-IOV를 사용하여 OpenDaylight 설치 링크 복사링크가 클립보드에 복사되었습니다!
시작하기 전에
- 언더클라우드를 설치합니다. 자세한 내용은 언더클라우드 설치를 참조하십시오.
- 오버클라우드 컨테이너 이미지에 대한 링크로 환경 파일을 생성합니다. 자세한 내용은 OpenDaylight를 사용하여 오버클라우드 설치 준비를 참조하십시오.
- SR-IOV 지원을 사용하여 사용자 지정 역할에 OpenDaylight를 구성하도록 역할 파일을 준비합니다. 자세한 내용은 SR-IOV 컴퓨팅 역할 준비를 참조하십시오.
절차
사용자 정의 역할 파일 및 필요한 환경 파일을 포함하도록
-r인수와 함께 배포 명령을 실행하여 OpenDaylight로 SR-IOV 기능을 활성화합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
배포 명령에 있는 환경 파일은 명령에 앞서 포함하는 환경 파일을 덮어씁니다. 실수로 매개 변수를 덮어쓰지 않도록 포함하는 환경 파일의 순서에 주의하십시오.
변경하려는 매개변수만 설정하고 기본 환경 파일과 결합하는 최소 환경 파일을 생성하여 일부 매개변수를 재정의할 수 있습니다.
더 많은 정보
-r옵션은 설치 시 역할 정의를 재정의합니다.-r <roles_data>.yaml
-r <roles_data>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 사용자 정의 역할에는 설치 중에 추가 ironic 노드가 필요합니다.
3.5. OVS-DPDK 지원을 사용하여 OpenDaylight 설치 링크 복사링크가 클립보드에 복사되었습니다!
OpenDaylight는 director와 함께 Open vSwitch DPDK(Data Plane Development Kit ) 가속을 통해 배포할 수 있습니다. 이 배포는 패킷이 커널 대신 사용자 공간에서 처리되므로 더 높은 데이터 플레인 성능을 제공합니다. OVS-DPDK를 사용하여 배포하려면 잠재적인 성능 이점을 활용하기 위해 각 컴퓨팅 노드의 하드웨어 물리적 레이아웃에 대한 지식이 필요합니다.
특히 다음을 고려해야 합니다.
- 호스트의 네트워크 인터페이스에서 DPDK를 지원하는 경우
- 컴퓨팅 노드의 NUMA 노드 토폴로지(소켓당 소켓 수, CPU 코어 및 메모리 수)
- DPDK NIC PCI 버스가 각 NUMA 노드에 근접
- 컴퓨팅 노드에서 사용 가능한 RAM 양
- 네트워크 기능 가상화 계획 및 구성 가이드 참조.
3.5.1. OVS-DPDK 배포 파일 준비 링크 복사링크가 클립보드에 복사되었습니다!
OVS-DPDK를 배포하려면 다른 환경 파일을 사용합니다. 이 파일은 /usr/share/openstack-tripleo-heat-templates/environments/services-docker 디렉터리의 neutron-opendaylight.yaml 환경 파일에 설정된 일부 매개 변수를 재정의합니다. 원래 환경 파일을 수정하지 마십시오. 대신 필요한 매개변수(예: neutron-opendaylight-dpdk.yaml )가 포함된 새 환경 파일을 생성합니다.
기본 설정을 사용하여 OVS-DPDK를 사용하여 OpenDaylight를 배포하려면 /usr/share/openstack-tripleo-heat-templates/environments/services-docker 디렉터리의 기본 neutron-opendaylight-dpdk.yaml 환경 파일을 사용합니다.
기본 파일에는 다음 값이 포함되어 있습니다.
3.5.2. OVS-DPDK 배포 구성 링크 복사링크가 클립보드에 복사되었습니다!
neutron-opendaylight-dpdk.yaml 의 값을 변경하여 OVS-DPDK 서비스를 구성할 수 있습니다.
|
|
OVS-DPDK와 함께 사용할 CPU 코어에서 분리하기 위해 IRQ를 고정할 수 있습니다. 기본 프로필: |
|
|
커널 스케줄러에서 OVS-DPDK 전용으로 할당할 수 있는 이러한 코어를 사용하지 못하도록 CPU 코어 목록을 지정합니다. 형식은 쉼표로 구분된 개인 또는 코어 범위(예: |
|
|
부팅 시 커널로 전달할 인수를 나열합니다. OVS-DPDK의 경우 IOMMU 및 Hugepages를 활성화해야 합니다
---- 지정된 RAM 용량은 hugepages의 경우 60GB입니다. 이 값을 설정할 때 컴퓨팅 노드에서 사용 가능한 RAM 용량을 고려하는 것이 중요합니다. |
|
| 각 NUMA 노드에 할당할 대규모 페이지 메모리(MB)의 양을 지정합니다. 최대 성능을 위해 DPDK NIC에 가장 가까운 소켓에 메모리를 할당합니다. 소켓당 메모리 형식 나열: ---- "<socket 0 mem MB>,<socket 1 mem MB>" ---- 예: "1024,0" |
|
|
PMD 스레드에서 사용할 UIO 드라이버 유형을 지정합니다. DPDK NIC는 지정된 드라이버를 지원해야 합니다. Red Hat OpenStack Platform 배포는 드라이버 유형 |
|
|
PMD 스레드가 고정될 단일 코어 또는 코어 범위를 나열합니다. 여기에 지정된 코어는 |
|
| 소켓당 메모리 채널 수를 지정합니다. |
|
| libvirtd 를 사용하여 nova 인스턴스를 에 고정하는 코어입니다. 최상의 성능을 위해 OVS PMD Core가 에 고정된 동일한 소켓의 코어를 사용합니다. |
3.5.3. OVS-DPDK를 사용하여 OpenDaylight 설치 링크 복사링크가 클립보드에 복사되었습니다!
시작하기 전에
- 언더클라우드를 설치합니다. 자세한 내용은 언더클라우드 설치를 참조하십시오.
- 오버클라우드 컨테이너 이미지에 대한 링크로 환경 파일을 생성합니다. 자세한 내용은 OpenDaylight를 사용하여 오버클라우드 설치 준비 를 참조하십시오.
- SR-IOV 지원을 사용하여 사용자 지정 역할에 OpenDaylight를 구성하도록 역할 파일을 준비합니다. 자세한 내용은 OVS-DPDK 배포 파일 준비를 참조하십시오.
절차
- 필요한 환경 파일과 함께 배포 명령을 실행하여 OpenDaylight에서 DPDK 기능을 활성화합니다.
배포 명령에 있는 환경 파일은 명령에 앞서 포함하는 환경 파일을 덮어씁니다. 실수로 매개 변수를 덮어쓰지 않도록 포함하는 환경 파일의 순서에 주의하십시오.
변경하려는 매개변수만 설정하고 기본 환경 파일과 결합하는 최소 환경 파일을 생성하여 일부 매개변수를 재정의할 수 있습니다.
3.5.4. 예: ODL 및 VXLAN 터널을 사용하여 OVS-DPDK 구성 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션에서는 ODL 및 VXLAN 터널을 사용한 OVS-DPDK의 구성에 대해 설명합니다.
OVS-DPDK의 OpenStack 네트워크를 최적화하려면 network-environment.yaml 파일에서 설정한 OVS-DPDK 매개변수에 가장 적합한 값을 결정해야 합니다. 자세한 내용은 워크플로를 사용하여 DPDK 매개변수 분리를 참조하십시오.
3.5.4.1. ComputeOvsDpdk 구성 가능 역할 생성 링크 복사링크가 클립보드에 복사되었습니다!
ComputeOvsDpdk 역할에 대한 roles_data.yaml 을 생성합니다.
openstack overcloud roles generate --roles-path templates/openstack-tripleo-heat-templates/roles -o roles_data.yaml Controller ComputeOvsDpdk
# openstack overcloud roles generate --roles-path templates/openstack-tripleo-heat-templates/roles -o roles_data.yaml Controller ComputeOvsDpdk
3.5.4.2. OVS-DPDK 매개변수 구성 링크 복사링크가 클립보드에 복사되었습니다!
OVS-DPDK의 OpenStack 네트워크를 최적화하려면 network-environment.yaml 파일에서 설정한 OVS-DPDK 매개변수에 가장 적합한 값을 결정해야 합니다. 자세한 내용은 https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/html/network_functions_virtualization_planning_and_configuration_guide/part-dpdk-configure#proc_derive-dpdk 을 참조하십시오.
resource_registry에서 OVS-DPDK에 대한 사용자 정의 리소스를 추가합니다.resource_registry: # Specify the relative/absolute path to the config files you want to use for override the default. OS::TripleO::ComputeOvsDpdk::Net::SoftwareConfig: nic-configs/computeovsdpdk.yaml OS::TripleO::Controller::Net::SoftwareConfig: nic-configs/controller.yamlresource_registry: # Specify the relative/absolute path to the config files you want to use for override the default. OS::TripleO::ComputeOvsDpdk::Net::SoftwareConfig: nic-configs/computeovsdpdk.yaml OS::TripleO::Controller::Net::SoftwareConfig: nic-configs/controller.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow parameter_defaults아래에서 터널 유형과 테넌트 유형을vxlan으로 설정합니다.NeutronTunnelTypes: 'vxlan' NeutronNetworkType: 'vxlan'
NeutronTunnelTypes: 'vxlan' NeutronNetworkType: 'vxlan'Copy to Clipboard Copied! Toggle word wrap Toggle overflow parameters_defaults에서 브리지 매핑을 설정합니다.# The OVS logical->physical bridge mappings to use. NeutronBridgeMappings: 'tenant:br-link0' OpenDaylightProviderMappings: 'tenant:br-link0'
# The OVS logical->physical bridge mappings to use. NeutronBridgeMappings: 'tenant:br-link0' OpenDaylightProviderMappings: 'tenant:br-link0'Copy to Clipboard Copied! Toggle word wrap Toggle overflow parameter_defaults에서ComputeOvsDpdk역할에 대한 역할별 매개변수를 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고게스트 인스턴스 생성에 실패를 방지하려면 DPDK PMD에 대해 DPDK NIC를 포함하거나 포함하지 않은 각 NUMA 노드에 하나 이상의 CPU를 할당해야 합니다.
참고이러한 대규모 페이지는 가상 머신에서 사용하며 이 프로세스에 표시된 대로
OvsDpdkSocketMemory매개변수를 사용하는 OVS-DPDK에서도 사용합니다. 가상 머신에서 사용할 수 있는 대규모 페이지 수는부팅매개변수입니다.OvsDpdkSocketMemory.DPDK 인스턴스와 연결된 플레이버에
hw:mem_page_size=1GB도 추가해야 합니다.참고OvsDPDKCoreList및OvsDpdkMemoryChannels는 이 절차에 필요한 설정입니다. 적절한 값 없이 DPDK를 배포하려고 하면 배포에 실패하거나 불안정한 배포가 발생합니다.
3.5.4.3. 컨트롤러 노드 구성 링크 복사링크가 클립보드에 복사되었습니다!
격리된 네트워크의 컨트롤 플레인 Linux 본딩을 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow VLAN을 이 Linux 본딩에 할당합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 클라우드 네트워크에 유동 IP에 액세스할 수 있도록 OVS 브리지를 만듭니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.5.4.4. DPDK 인터페이스에 대한 컴퓨팅 노드 구성 링크 복사링크가 클립보드에 복사되었습니다!
기본 compute.yaml 파일에서 compute-ovs-dpdk.yaml 파일을 생성하고 다음과 같이 변경합니다.
격리된 네트워크의 컨트롤 플레인 Linux 본딩을 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow VLAN을 이 Linux 본딩에 할당합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow DPDK 포트가 있는 브릿지를 설정하여 컨트롤러에 연결합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고여러 DPDK 장치를 포함하려면 추가할 각 DPDK 장치에 대한
유형코드 섹션을 반복합니다.참고OVS-DPDK를 사용하는 경우 동일한 컴퓨팅 노드의 모든 브릿지는
ovs_user_bridge여야 합니다. director는 설정을 허용하지만 Red Hat OpenStack Platform은 동일한 노드에서ovs_bridge및ovs_user_bridge혼합을 지원하지 않습니다.
3.5.4.5. 오버클라우드 배포 링크 복사링크가 클립보드에 복사되었습니다!
overcloud_deploy.sh 스크립트를 실행하여 오버클라우드를 배포합니다.
3.6. L2GW 지원을 사용하여 OpenDaylight 설치 링크 복사링크가 클립보드에 복사되었습니다!
이 기능은 이번 릴리스에서 기술 프리뷰로 제공되므로 Red Hat에서 완전히 지원되지 않습니다. 테스트 용도로만 사용해야 하며 프로덕션 환경에 배포해서는 안 됩니다. 기술 프리뷰 기능에 대한 자세한 내용은 적용 범위 상세 정보를 참조하십시오.
계층 2 게이트웨이 서비스를 사용하면 테넌트의 가상 네트워크를 물리적 네트워크에 연결할 수 있습니다. 이러한 통합을 통해 사용자는 라우팅된 계층 3 연결을 통하지 않고 계층 2 네트워크 연결을 통해 물리적 서버의 리소스에 액세스할 수 있습니다. 즉, L3 또는 유동 IP를 거치지 않고 계층 2 브로드캐스트 도메인을 확장합니다.
3.6.1. L2GW 배포 파일 준비 링크 복사링크가 클립보드에 복사되었습니다!
L2GW 지원을 사용하여 OpenDaylight를 배포하려면 /usr/share/openstack-tripleo-heat-templates/environments 디렉터리에 있는 neutron-l2gw-opendaylight.yaml 파일을 사용합니다. 해당 파일에서 설정을 변경해야 하는 경우 기존 파일을 수정하지 마십시오. 대신 필요한 매개 변수가 포함된 환경 파일의 새 복사본을 생성합니다.
기본 설정으로 OpenDaylight 및 L2GW를 배포하려면 /usr/share/openstack-tripleo-heat-templates/environment-docker 디렉터리에서 을 사용할 수 있습니다.
neutron-l2gw- opendaylight.yaml
기본 파일에는 다음 값이 포함되어 있습니다.
3.6.2. OpenDaylight L2GW 배포 구성 링크 복사링크가 클립보드에 복사되었습니다!
neutron-l2gw-opendaylight.yaml 파일에서 값을 변경하여 서비스를 구성할 수 있습니다.
|
|
|
|
|
이 서비스를 제공하는 데 사용해야 하는 공급자를 정의합니다. 기본값은 |
|
| 기본 인터페이스의 이름을 설정합니다. |
|
| 기본 장치의 이름을 설정합니다. |
|
|
L2 게이트웨이의 서비스 할당량을 지정합니다. 기본값은 |
|
| L2GW 서비스의 모니터링 간격을 지정합니다. |
3.6.3. L2GW로 OpenDaylight 설치 링크 복사링크가 클립보드에 복사되었습니다!
시작하기 전에
- 언더클라우드를 설치합니다. 자세한 내용은 언더클라우드 설치를 참조하십시오.
- 오버클라우드 컨테이너 이미지에 대한 링크로 환경 파일을 생성합니다. 자세한 내용은 OpenDaylight를 사용하여 오버클라우드 설치 준비 를 참조하십시오.
- SR-IOV 지원을 사용하여 사용자 지정 역할에 OpenDaylight를 구성하도록 역할 파일을 준비합니다. 자세한 내용은 L2GW 배포 파일 준비를 참조하십시오.
절차
- 필요한 환경 파일과 함께 배포 명령을 실행하여 OpenDaylight로 L2GW 기능을 활성화합니다.
배포 명령에 있는 환경 파일은 명령에 앞서 포함하는 환경 파일을 덮어씁니다. 실수로 매개 변수를 덮어쓰지 않도록 포함하는 환경 파일의 순서에 주의하십시오.
변경하려는 매개변수만 설정하고 기본 환경 파일과 결합하는 최소 환경 파일을 생성하여 일부 매개변수를 재정의할 수 있습니다.
4장. 배포 테스트 링크 복사링크가 클립보드에 복사되었습니다!
4.1. 기본 테스트 수행 링크 복사링크가 클립보드에 복사되었습니다!
기본 테스트에서는 인스턴스가 서로 ping할 수 있는지 확인합니다. 테스트에서는 유동 IP SSH 액세스도 확인합니다. 이 예제에서는 언더클라우드에서 이 테스트를 수행하는 방법을 설명합니다.
이 절차를 수행하려면 많은 개별 단계를 수행해야 합니다. 편의를 위해 이 절차는 더 작은 부분으로 나뉩니다. 그러나 다음 순서로 모든 단계를 수행해야 합니다.
In this setup, a flat network is used to create the _External_ network, and _VXLAN_ is used for the _Tenant_ networks. _VLAN External_ networks and _VLAN Tenant_ networks are also supported, depending on the desired deployment.
In this setup, a flat network is used to create the _External_ network, and _VXLAN_ is used for the _Tenant_ networks. _VLAN External_ networks and _VLAN Tenant_ networks are also supported, depending on the desired deployment.
4.1.1. 테스트를 위한 새 네트워크 만들기 링크 복사링크가 클립보드에 복사되었습니다!
오버클라우드에 액세스하기 위해 인증 정보를 가져옵니다.
source /home/stack/overcloudrc
$ source /home/stack/overcloudrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow 외부 neutron 네트워크를 생성하여 오버클라우드 외부에서 인스턴스에 액세스합니다.
openstack network create --external --project service --external --provider-network-type flat --provider-physical-network datacentre external
$ openstack network create --external --project service --external --provider-network-type flat --provider-physical-network datacentre externalCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이전 단계에서 생성한 새 외부 네트워크에 해당하는 neutron 서브넷을 생성합니다.
openstack subnet create --project service --no-dhcp --network external --gateway 192.168.37.1 --allocation-pool start=192.168.37.200,end=192.168.37.220 --subnet-range 192.168.37.0/24 external-subnet
$ openstack subnet create --project service --no-dhcp --network external --gateway 192.168.37.1 --allocation-pool start=192.168.37.200,end=192.168.37.220 --subnet-range 192.168.37.0/24 external-subnetCopy to Clipboard Copied! Toggle word wrap Toggle overflow 오버클라우드 인스턴스를 생성하는 데 사용할 cirros 이미지를 다운로드합니다.
wget http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img
$ wget http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.imgCopy to Clipboard Copied! Toggle word wrap Toggle overflow 오버클라우드의 glance에 cirros 이미지를 업로드합니다.
openstack image create cirros --public --file ./cirros-0.3.4-x86_64-disk.img --disk-format qcow2 --container-format bare
$ openstack image create cirros --public --file ./cirros-0.3.4-x86_64-disk.img --disk-format qcow2 --container-format bareCopy to Clipboard Copied! Toggle word wrap Toggle overflow 오버클라우드 인스턴스에 사용할
작은 플레이버를 만듭니다.openstack flavor create m1.tiny --ram 512 --disk 1 --public
$ openstack flavor create m1.tiny --ram 512 --disk 1 --publicCopy to Clipboard Copied! Toggle word wrap Toggle overflow 인스턴스를 호스팅할 VXLAN 테넌트 네트워크를 만듭니다.
openstack network create net_test --provider-network-type=vxlan --provider-segment 100
$ openstack network create net_test --provider-network-type=vxlan --provider-segment 100Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이전 단계에서 만든 테넌트 네트워크의 서브넷을 생성합니다.
openstack subnet create --network net_test --subnet-range 123.123.123.0/24 test
$ openstack subnet create --network net_test --subnet-range 123.123.123.0/24 testCopy to Clipboard Copied! Toggle word wrap Toggle overflow 테넌트 네트워크의 ID를 찾아서 저장합니다.
net_mgmt_id=$(openstack network list | grep net_test | awk '{print $2}')$ net_mgmt_id=$(openstack network list | grep net_test | awk '{print $2}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow cirros1인스턴스를 만들고net_test네트워크 및SSH보안 그룹에 연결합니다.openstack server create --flavor m1.tiny --image cirros --nic net-id=$vlan1 --security-group SSH --key-name RDO_KEY --availability-zone nova:overcloud-novacompute-0.localdomain cirros1
$ openstack server create --flavor m1.tiny --image cirros --nic net-id=$vlan1 --security-group SSH --key-name RDO_KEY --availability-zone nova:overcloud-novacompute-0.localdomain cirros1Copy to Clipboard Copied! Toggle word wrap Toggle overflow net_test네트워크 및SSH보안 그룹에도 연결된 두 번째 인스턴스cirros2를 만듭니다.openstack server create --flavor m1.tiny --image cirros --nic net-id=$vlan1 --security-group SSH --key-name RDO_KEY --availability-zone nova:overcloud-novacompute-0.localdomain cirros2
$ openstack server create --flavor m1.tiny --image cirros --nic net-id=$vlan1 --security-group SSH --key-name RDO_KEY --availability-zone nova:overcloud-novacompute-0.localdomain cirros2Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.2. 테스트 환경에서 네트워킹 설정 링크 복사링크가 클립보드에 복사되었습니다!
admin 프로젝트의 ID를 찾아서 저장합니다.
admin_project_id=$(openstack project list | grep admin | awk '{print $2}')$ admin_project_id=$(openstack project list | grep admin | awk '{print $2}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow admin 프로젝트의 기본 보안 그룹을 찾아 저장합니다.
admin_sec_group_id=$(openstack security group list | grep $admin_project_id | awk '{print $2}')$ admin_sec_group_id=$(openstack security group list | grep $admin_project_id | awk '{print $2}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow ICMP 트래픽 수신을 허용하도록 admin default 보안 그룹에 규칙을 추가합니다.
openstack security group rule create $admin_sec_group_id --protocol icmp --ingress
$ openstack security group rule create $admin_sec_group_id --protocol icmp --ingressCopy to Clipboard Copied! Toggle word wrap Toggle overflow ICMP 트래픽 송신을 허용하도록 admin default 보안 그룹에 규칙을 추가합니다.
openstack security group rule create $admin_sec_group_id --protocol icmp --egress
$ openstack security group rule create $admin_sec_group_id --protocol icmp --egressCopy to Clipboard Copied! Toggle word wrap Toggle overflow admin default 보안 그룹에 규칙을 추가하여 SSH 트래픽 수신을 허용합니다.
openstack security group rule create $admin_sec_group_id --protocol tcp --dst-port 22 --ingress
$ openstack security group rule create $admin_sec_group_id --protocol tcp --dst-port 22 --ingressCopy to Clipboard Copied! Toggle word wrap Toggle overflow admin default 보안 그룹에 규칙을 추가하여 SSH 트래픽 송신을 허용합니다.
openstack security group rule create $admin_sec_group_id --protocol tcp --dst-port 22 --egress
$ openstack security group rule create $admin_sec_group_id --protocol tcp --dst-port 22 --egressCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.3. 연결 테스트 링크 복사링크가 클립보드에 복사되었습니다!
-
horizon에서 인스턴스의 novnc 콘솔에 액세스할 수 있어야 합니다. overcloudrc 의 암호를 사용하여 admin 으로 horizon에 로그인합니다. cirros 이미지의 기본 인증 정보는 사용자 이름
cirros및 암호cubswin:)입니다. novnc 콘솔에서 인스턴스에서 DHCP 주소를 수신하는지 확인합니다.
ip addr show
$ ip addr showCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고언더클라우드에서
nova console-log <instance id> 명령을 실행하여 인스턴스에서 DHCP 주소를 수신하는지 확인할 수도 있습니다.- 다른 모든 인스턴스에 대해 1 및 2단계를 반복합니다.
- 한 인스턴스에서 다른 인스턴스를 ping합니다. 이렇게 하면 오버클라우드의 기본 테넌트 네트워크 연결이 검증됩니다.
- 유동 IP 를 사용하여 다른 인스턴스에 연결할 수 있는지 확인합니다.
4.1.4. 장치 생성 링크 복사링크가 클립보드에 복사되었습니다!
cirros1인스턴스와 연결할 외부 네트워크에 유동 IP를 만듭니다.openstack floating ip create external
$ openstack floating ip create externalCopy to Clipboard Copied! Toggle word wrap Toggle overflow 유동 IP와
cirros1테넌트 IP 간에 NAT를 처리하는 라우터를 만듭니다.openstack router create test
$ openstack router create testCopy to Clipboard Copied! Toggle word wrap Toggle overflow 라우터의 게이트웨이를 외부 네트워크로 설정합니다.
openstack router set test --external-gateway external
$ openstack router set test --external-gateway externalCopy to Clipboard Copied! Toggle word wrap Toggle overflow 테넌트 네트워크에 연결된 라우터에 인터페이스를 추가합니다.
openstack router add subnet test test
$ openstack router add subnet test testCopy to Clipboard Copied! Toggle word wrap Toggle overflow 1단계에서 만든 유동 IP를 찾아 저장합니다.
floating_ip=$(openstack floating ip list | head -n -1 | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+')
$ floating_ip=$(openstack floating ip list | head -n -1 | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 유동 IP를
cirros1인스턴스와 연결합니다.openstack server add floating ip cirros1 $floating_ip
$ openstack server add floating ip cirros1 $floating_ipCopy to Clipboard Copied! Toggle word wrap Toggle overflow 외부 네트워크 액세스 권한이 있는 노드에서 인스턴스에 로그인합니다.
ssh cirros@$floating_ip
$ ssh cirros@$floating_ipCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.2. 고급 테스트 수행 링크 복사링크가 클립보드에 복사되었습니다!
OpenDaylight를 배포한 후 OpenDaylight 구성 및 배포의 여러 구성 요소를 테스트할 수 있습니다. 설치의 특정 부분을 테스트하려면 여러 절차를 따라야 합니다. 각 절차는 개별적으로 설명됩니다.
오버클라우드 노드에서 절차를 수행해야 합니다.
4.2.1. 오버클라우드 노드에 연결 링크 복사링크가 클립보드에 복사되었습니다!
오버클라우드 노드에 연결하고 올바르게 작동하는지 확인하려면 다음 단계를 완료합니다.
절차
- 언더클라우드에 로그인합니다.
다음 명령을 입력하여 프로세스를 시작합니다.
source /home/stack/stackrc
$ source /home/stack/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow 모든 인스턴스를 나열합니다.
openstack server list
$ openstack server listCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 필요한 인스턴스를 선택하고 목록에서 인스턴스 IP 주소를 기록합니다.
이전 단계에서 얻은 목록에서 IP 주소를 사용하여 머신에 연결합니다.
ssh heat-admin@<IP from step 4>
$ ssh heat-admin@<IP from step 4>Copy to Clipboard Copied! Toggle word wrap Toggle overflow superuser로 전환합니다.
sudo -i
$ sudo -iCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.2.2. OpenDaylight 테스트 링크 복사링크가 클립보드에 복사되었습니다!
OpenDaylight가 올바르게 작동하는지 테스트하려면 서비스가 작동하고 지정된 기능이 올바르게 로드되었는지 확인해야 합니다.
절차
- 수퍼유저로 OpenDaylight를 실행하는 오버클라우드 노드에 로그인하거나 사용자 지정 역할로 실행 중인 OpenDaylight 노드에 로그인합니다.
OpenDaylight 컨트롤러가 모든 컨트롤러 노드에서 실행 중인지 확인합니다.
docker ps | grep opendaylight 2363a99d514a 192.168.24.1:8787/rhosp13/openstack-opendaylight:latest "kolla_start" 4 hours ago Up 4 hours (healthy) opendaylight_api
# docker ps | grep opendaylight 2363a99d514a 192.168.24.1:8787/rhosp13/openstack-opendaylight:latest "kolla_start" 4 hours ago Up 4 hours (healthy) opendaylight_apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow HAProxy가 포트 8081에서 수신 대기하도록 올바르게 구성되었는지 확인합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow HAproxy IP를 사용하여 karaf 계정을 연결합니다. karaf 암호는
karaf:ssh -p 8101 karaf@localhost
# ssh -p 8101 karaf@localhostCopy to Clipboard Copied! Toggle word wrap Toggle overflow 설치된 기능을 나열합니다.
feature:list -i | grep odl-netvirt-openstack
# feature:list -i | grep odl-netvirt-openstackCopy to Clipboard Copied! Toggle word wrap Toggle overflow 절차 중에 생성된 것처럼 목록의 세 번째 열에
x가 있는 경우 기능이 올바르게 설치됩니다.API가 작동하는지 확인합니다.
web:list | grep neutron
# web:list | grep neutronCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이 API 엔드포인트는
/etc/neutron/plugins/ml2/ml2_conf.ini에 설정되어 있으며 neutron이 OpenDaylight와 통신하는 데 사용됩니다.노드 간 VXLAN 터널이 작동 중인지 확인합니다.
vxlan:show
# vxlan:showCopy to Clipboard Copied! Toggle word wrap Toggle overflow REST API가 올바르게 응답하는지 테스트하려면 해당 API를 사용하는 모듈을 나열합니다.
curl -u "admin:admin" http://localhost:8081/restconf/modules
# curl -u "admin:admin" http://localhost:8081/restconf/modulesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력은 유사할 것입니다(예가 단축됨).
{"modules":{"module":[{"name":"netty-event-executor","revision":"2013-11-12","namespace":"urn:opendaylight:params:xml:ns:yang:controller:netty:eventexecutor"},{"name" ...{"modules":{"module":[{"name":"netty-event-executor","revision":"2013-11-12","namespace":"urn:opendaylight:params:xml:ns:yang:controller:netty:eventexecutor"},{"name" ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 호스트 internal_API IP를 사용하는 REST 스트림을 나열합니다.
curl -u "admin:admin" http://localhost:8081/restconf/streams
# curl -u "admin:admin" http://localhost:8081/restconf/streamsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같은 출력이 표시됩니다.
{"streams":{}}{"streams":{}}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 내부_API IP와 함께 실행하여 NetVirt가 작동하는지 확인합니다.
curl -u "admin:admin" http://localhost:8081/restconf/operational/network-topology:network-topology/topology/netvirt:1
# curl -u "admin:admin" http://localhost:8081/restconf/operational/network-topology:network-topology/topology/netvirt:1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 출력에서 NetVirt가 작동하는지 확인합니다.
{"topology":[{"topology-id":"netvirt:1"}]}{"topology":[{"topology-id":"netvirt:1"}]}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.2.3. Open vSwitch 테스트 링크 복사링크가 클립보드에 복사되었습니다!
Open vSwitch 를 확인하려면 컴퓨팅 노드 중 하나에 연결하고 올바르게 구성되어 OpenDaylight에 연결되어 있는지 확인합니다.
절차
- 수퍼유저로 오버클라우드의 컴퓨팅 노드 중 하나에 연결합니다.
Open vSwitch 설정을 나열합니다.
ovs-vsctl show
# ovs-vsctl showCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력의 여러 관리자를 확인합니다. 이 예제에서는 2행과 3행이 여러 관리자를 표시합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
tcp관리자가 OpenDaylight가 실행 중인 노드의 IP를 가리키는지 확인합니다. -
OVS의 OpenDaylight에 연결하고 OVSDB 프로토콜을 사용하는지 확인하려면 Managers show
is_connected: true를 확인합니다. - 각 브리지( br-int이외의)가 있으며 Compute 역할과 함께 배포에 사용되는 NIC 템플릿에 해당하는지 확인합니다.
- tcp 연결이 OpenDaylight 서비스가 실행 중인 IP에 해당하는지 확인합니다.
-
br-int 에
is_connected: true브리지가 표시되고 OpenDaylight에 대한 OpenFlow 프로토콜 연결이 설정되었는지 확인합니다.
더 많은 정보
- OpenDaylight는 br-int 브리지를 자동으로 생성합니다.
4.2.4. 컴퓨팅 노드에서 Open vSwitch 구성을 확인합니다. 링크 복사링크가 클립보드에 복사되었습니다!
- 수퍼유저로 컴퓨팅 노드에 연결합니다.
Open vSwitch 구성 설정을 나열합니다.
ovs-vsctl list open_vswitch
# ovs-vsctl list open_vswitchCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력을 읽습니다. 이 예와 유사합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
other_config옵션의 값에 VXLAN 터널을 통해 테넌트 네트워크에 연결되는 로컬 인터페이스에 대해 올바른local_ip세트가 있는지 확인합니다. -
other_config옵션 아래의provider_mappings값이 OpenDaylightProviderMappings heat 템플릿 매개변수의 값과 일치하는지 확인합니다. 이 구성은 neutron 논리적 네트워크를 해당 물리 인터페이스에 매핑합니다.
4.2.5. neutron 구성 확인 링크 복사링크가 클립보드에 복사되었습니다!
절차
- 컨트롤러 역할 노드 중 하나에서 수퍼유저 계정에 연결합니다.
-
/etc/neutron/neutron.conf파일에service_plugins=odl-router_v2,trunk가 포함되어 있는지 확인합니다. /etc/neutron/plugin.ini파일에 다음 ml2 구성이 포함되어 있는지 확인합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Overcloud 컨트롤러 중 하나에서 neutron 에이전트가 올바르게 실행되고 있는지 확인합니다.
openstack network agent list
# openstack network agent listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 메타데이터 및 DHCP 에이전트의
admin_state_up값이True인지 확인합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
더 많은 정보
-
3단계에서 언급한
plugin.ini의 IP는 InternalAPI 가상 IP 주소(VIP)여야 합니다. - 이제 OpenDaylight에서 모두 관리되므로 5단계 출력에 나열된 Open vSwitch 에이전트 또는 L3 에이전트가 없습니다.
5장. 디버깅 링크 복사링크가 클립보드에 복사되었습니다!
5.1. 로그 찾기 링크 복사링크가 클립보드에 복사되었습니다!
5.1.1. OpenDaylight 로그 액세스 링크 복사링크가 클립보드에 복사되었습니다!
OpenDaylight는 /var/log/containers/opendaylight 디렉터리의 컨테이너에 로그를 저장합니다. 가장 최근의 로그의 이름은 karaf.log 입니다. OpenDaylight는 이전 로그에 증분 번호를 추가합니다(예: karaf.log.1,karaf.log. 2).
5.1.2. OpenStack Networking 로그에 액세스 링크 복사링크가 클립보드에 복사되었습니다!
OpenStack 네트워킹 명령이 실패하면 먼저 neutron 로그를 검사합니다. /var/log/containers/neutron 디렉터리의 각 neutron 노드의 server.log 파일에서 neutron 로그를 찾을 수 있습니다.
server.log 파일에는 OpenDaylight와의 통신 관련 오류도 포함되어 있습니다. neutron 오류가 OpenDaylight와 상호 작용에서 시작되는 경우 OpenDaylight 로그를 검사하여 실패 원인을 찾아야 합니다.
5.2. 네트워킹 오류 디버그 링크 복사링크가 클립보드에 복사되었습니다!
인스턴스 연결 손실과 같은 네트워크 오류가 발생하지만 OpenStack 명령 또는 neutron 로그를 실행할 때 오류가 보고되지 않으면 OVS 노드에서 네트워크 트래픽 및 OpenFlow 흐름을 검사하는 것이 유용할 수 있습니다.
-
네트워크 오류가 발생하는 노드에 수퍼유저로 로그인합니다.
br-int 스위치에 대한 정보를 표시합니다.
ovs-ofctl -O openflow13 show br-int
# ovs-ofctl -O openflow13 show br-intCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력을 검사합니다. 다음 예와 유사해야 합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow br-int 스위치의 통계를 나열합니다.
ovs-ofctl -O openflow13 dump-ports br-int
# ovs-ofctl -O openflow13 dump-ports br-intCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력을 검사합니다. 다음 예와 유사해야 합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
더 많은 정보
- 3단계에서 는 이 OVS 노드에 세 개의 포트가 있습니다. 첫 번째 포트는 이 시나리오에서 외부 네트워크 연결 포트인 br-ex 브리지로 이동하는 패치 포트입니다. 두 번째 포트는 DHCP 에이전트 인스턴스에 연결하는 탭 포트입니다. 호스트가 컨트롤러이기 때문에 이를 알고 있습니다. 그렇지 않으면 Compute 역할에 따라 인스턴스가 됩니다. 세 번째 포트는 테넌트 트래픽에 대해 생성된 VXLAN 터널 포트입니다.
- 각 포트가 무엇인지 이해하면 포트 통계를 검사하여 포트가 트래픽을 수신하고 있는지 확인할 수 있습니다( 단계 4 단계참조).
- 5단계 의 출력에서 각 포트가 수신(rx pkts) 및 패킷 전송(tx pkts)을 확인합니다.
5.2.1. OpenFlow 흐름을 사용한 고급 디버깅 링크 복사링크가 클립보드에 복사되었습니다!
OpenFlow에 익숙한 고급 사용자의 경우 스위치의 흐름을 검사하여 트래픽이 떨어지는 위치를 탐지할 수 있습니다.
흐름을 나열하고 패킷 수를 보려면 다음 명령을 입력합니다.
ovs-ofctl -O openflow13 dump-flows br-int
# ovs-ofctl -O openflow13 dump-flows br-intCopy to Clipboard Copied! Toggle word wrap Toggle overflow 명령 출력을 검사하여 필요한 정보를 가져옵니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
이 출력은 길이에 맞게 편집되었습니다.
5.2.2. OpenFlow에서 패킷 트래버스 링크 복사링크가 클립보드에 복사되었습니다!
중요한 점은 패킷에서 수행되는 네트워크 기능이 서로 다른 OpenFlow 테이블로 분할되고 패킷이 0부터 시작하여 해당 테이블을 순서대로 통과한다는 것입니다. 들어오는 패킷은 표 0에 있는 다음, 포트 밖으로 전송되거나 OpenDaylight Controller로 삭제될 때까지 OpenFlow 파이프라인 을 통해 진행됩니다. 패킷이 하나 이상의 테이블을 건너뛸 수 있으며, 이 테이블은 어떤 네트워크 기능으로 이동해야 하는지에 따라 달라집니다. 테이블의 전체 다이어그램 및 네트워크 기능에 해당하는 방법은 다음과 같습니다.
그림 5.1. OpenDaylight NetVirt OpenFlow Pipeline
6장. 배포 예 링크 복사링크가 클립보드에 복사되었습니다!
6.1. 테넌트 네트워크를 사용하는 모델 설치 시나리오 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션에서는 프로덕션 환경에서 OpenStack을 사용한 OpenDaylight 설치 예를 살펴봅니다. 이 시나리오에서는 테넌트 트래픽 분리에 터널링(VXLAN)을 사용합니다.
6.1.1. 물리적 토폴로지 링크 복사링크가 클립보드에 복사되었습니다!
이 시나리오의 토폴로지는 6개의 노드로 구성됩니다.
- x director 언더클라우드 노드 1개
- 다른 OpenStack 서비스 외에도 OpenDaylight SDN 컨트롤러가 설치된 x OpenStack overcloud 컨트롤러 3
- 두 개의 x OpenStack 오버클라우드 컴퓨팅 노드
6.1.2. 물리적 네트워크 환경 계획 링크 복사링크가 클립보드에 복사되었습니다!
오버클라우드 컨트롤러 노드는 각각 3개의 NIC(네트워크 인터페이스 카드)를 사용합니다.
| 이름 | 목적 |
|---|---|
| nic1 | 관리 네트워크(예: SSH를 통해 노드에 액세스) |
| nic2 | 테넌트 (VXLAN) 캐리어, 프로비저닝 (PXE, DHCP), 내부 API 네트워크 |
| nic3 | 공용 API 네트워크 액세스 |
오버클라우드 컴퓨팅 노드에는 다음 세 개의 NIC가 제공됩니다.
| 이름 | 목적 |
|---|---|
| nic1 | 관리 네트워크 |
| nic2 | 테넌트 통신업체, 프로비저닝 및 내부 API 네트워크 |
| nic3 | external (Floating IP) 네트워크 |
언더클라우드 노드에는 두 개의 NIC가 제공됩니다.
| 이름 | 목적 |
|---|---|
| nic1 | 관리 네트워크에 사용 |
| nic2 | 프로비저닝 네트워크에 사용 |
6.1.3. 계획 NIC Connectivity 링크 복사링크가 클립보드에 복사되었습니다!
이 경우 환경 파일은 추상 번호가 지정된 인터페이스(nic1,nic2)를 사용하며 호스트 운영 체제( eth0 또는 eno2)에 제공되는 실제 장치 이름은 아닙니다. 동일한 역할에 속하는 호스트에는 동일한 네트워크 인터페이스 장치 이름이 필요하지 않습니다. 한 호스트에서 em1 및 em2 인터페이스를 사용하는 반면 다른 호스트에서 eno1 및 eno2 를 사용하는 경우 문제가 없습니다. 각 NIC를 nic1 및 nic2 라고 합니다.
추상화된 NIC 스키마는 실시간 및 연결된 인터페이스에만 의존합니다. 호스트에 다른 수의 인터페이스가 있는 경우 호스트를 연결하는 데 필요한 최소한의 인터페이스를 사용하는 것으로 충분합니다. 예를 들어, 한 호스트에 4개의 물리적 인터페이스가 있고 다른 호스트에 6개의 물리적 인터페이스가 있는 경우 nic1,nic2,nic3, nic4 를 사용하고 두 호스트의 4개의 케이블로 연결해야합니다.
6.1.4. 네트워크, VLAN 및 IP 계획 링크 복사링크가 클립보드에 복사되었습니다!
이 시나리오에서는 네트워크 분리를 사용하여 관리, 프로비저닝, 내부 API, 테넌트, 공용 API 및 유동 IP 네트워크 트래픽을 분리합니다. 이 그래픽은 네트워크 구성의 예입니다. 사용자 지정 역할 배포를 보여줍니다. 필요한 경우 Red Hat OpenStack Platform conroller에 OpenDaylight를 포함할 수도 있습니다. 이는 기본 설정입니다. 이 스키마 IPMI 네트워크에 NIC 및 라우팅이 표시되지 않습니다. OpenStack 구성에 따라 추가 네트워크가 필요할 수 있습니다.
그림 6.1. 이 시나리오에서 사용되는 세부 네트워크 토폴로지
표에는 각 네트워크와 연결된 VLAN ID 및 IP 서브넷이 표시됩니다.
| 네트워크 | VLAN ID | IP Subnet |
|---|---|---|
| 프로비저닝 | 실제 하드웨어에 적용 | 192.0.5.0/24 |
| 내부 API | 600 | 172.17.0.0/24 |
| 테넌트 | 603 | 172.16.0.0/24 |
| 공용 API | 411 | 10.35.184.144/28 |
| 부동 IP | 412 | 10.35.186.146/28 |
OpenStack Platform director는 br-isolated OVS 브리지를 생성하고 네트워크 구성 파일에 정의된 대로 각 네트워크의 VLAN 인터페이스를 추가합니다. director는 관련 네트워크 인터페이스가 연결된 br-ex 브리지도 생성합니다.
호스트 간에 연결을 제공하는 물리적 네트워크 스위치가 해당 VLAN ID 를 전달하도록 올바르게 구성되었는지 확인합니다. VLAN 을 사용하여 호스트를 대상으로 하는 모든 스위치 포트를 "trunks"로 구성해야 합니다. 여기서 "trunk"라는 용어는 여러 VLAN ID 가 동일한 포트를 통과할 수 있는 포트를 설명하는 데 사용됩니다.
물리적 스위치에 대한 구성 지침은 이 문서의 범위를 벗어납니다.
network-environment.yaml 파일에서 TenantNetworkVlanID 특성을 사용하여 VXLAN 터널링을 사용할 때 테넌트 네트워크에 대한 VLAN 태그를 정의할 수 있습니다. 예를 들어 VXLAN 테넌트 트래픽이 VLAN 태그된 오버레이 네트워크를 통해 전송됩니다. 테넌트 네트워크가 기본 VLAN을 통해 실행하려는 경우에도 이 값을 비워 둘 수 있습니다. 또한 VLAN 테넌트 유형 네트워크를 사용할 때 TenantNetworkVlanID 에 제공된 값 이외의 VLAN 태그를 사용할 수 있습니다.
6.1.5. 이 시나리오에서 사용되는 OpenDaylight 구성 파일 링크 복사링크가 클립보드에 복사되었습니다!
OpenStack 및 OpenDaylight의 이 시나리오를 배포하려면 언더클라우드 노드에 다음 배포 명령이 입력되었습니다.
또한 이 가이드에서는 이 시나리오에서 사용되는 구성 파일, 콘텐츠도 표시되며 사용된 설정에 대한 설명도 제공합니다.
6.1.5.1. extra_env.yaml 파일 링크 복사링크가 클립보드에 복사되었습니다!
파일에는 하나의 매개변수만 있습니다.
parameter_defaults:
OpenDaylightProviderMappings: 'datacentre:br-ex,tenant:br-isolated'
parameter_defaults:
OpenDaylightProviderMappings: 'datacentre:br-ex,tenant:br-isolated'
이러한 매핑은 OpenDaylight에서 제어하는 각 노드에서 사용할 매핑입니다. 물리적 네트워크 데이터 센터 는 br-ex OVS 브리지에 매핑되고 테넌트 네트워크 트래픽은 br-isolated OVS 브리지에 매핑됩니다.
6.1.5.2. undercloud.conf 파일 링크 복사링크가 클립보드에 복사되었습니다!
이 파일은 /home/stack/baremetal-vlan/ 디렉터리에 있습니다.
파일 경로는 사용자 지정된 구성 파일의 버전을 가리킵니다.
이 예에서는 프로비저닝 네트워크의 192.0.5.0/24 서브넷이 사용됩니다. 물리적 인터페이스 eno2 는 프로비저닝을 위해 언더클라우드 노드에서 사용됩니다.
6.1.5.3. network-environment.yaml 파일 링크 복사링크가 클립보드에 복사되었습니다!
이 파일은 네트워크를 구성하는 데 사용되는 기본 파일입니다. /home/stack/baremetal-vlan/ 디렉터리에 있습니다. 다음 파일에서 VLAN ID 및 IP 서브넷은 다른 네트워크와 공급자 매핑에 대해 지정됩니다. nic-configs 디렉터리 controller.yaml 및 compute.yaml 의 두 파일은 컨트롤러 및 컴퓨팅 노드의 네트워크 구성을 지정하는 데 사용됩니다.
컨트롤러 노드 (3) 및 컴퓨팅 노드(2)의 수가 예에 지정되어 있습니다.
6.1.5.4. controller.yaml 파일 링크 복사링크가 클립보드에 복사되었습니다!
파일은 /home/stack/baremetal-vlan/nic-configs/ 디렉터리에 있습니다. 이 예제에서는 br-isolated 및 br-ex 의 스위치 두 개를 정의합니다. nic2 는 br-isolated 및 nic3 아래에 있습니다.
6.1.5.5. compute.yaml 파일 링크 복사링크가 클립보드에 복사되었습니다!
파일은 /home/stack/baremetal-vlan/nic-configs/ 디렉터리에 있습니다. 컴퓨팅 구성의 대부분의 옵션은 컨트롤러 구성과 동일합니다. 이 예제에서 nic3 는 외부 연결에 사용할 br-ex 아래에 있습니다(IP 네트워크 연결 )
6.1.6. 이 시나리오에서 사용되는 Red Hat OpenStack Platform director 구성 파일 링크 복사링크가 클립보드에 복사되었습니다!
6.1.6.1. neutron.conf 파일 링크 복사링크가 클립보드에 복사되었습니다!
이 파일은 /etc/neutron/ 디렉터리에 있으며 다음 정보가 포함되어야 합니다.
[DEFAULT] service_plugins=odl-router_v2,trunk
[DEFAULT]
service_plugins=odl-router_v2,trunk
6.1.6.2. ml2_conf.ini 파일 링크 복사링크가 클립보드에 복사되었습니다!
이 파일은 /etc/neutron/plugins/ml2/ 디렉터리에 있으며 다음 정보가 포함되어야 합니다.
- [ml2] 섹션에서 VXLAN은 네트워크 유형으로 사용되며 opendaylight_v2 메커니즘 드라이버입니다.
- [ml2_type_vlan]에서 network-environment.yaml 파일에 구성된 것과 동일한 매핑을 설정해야 합니다.
- [ml2_odl] 아래에 OpenDaylightController에 액세스하는 구성이 표시되어야 합니다.
이러한 세부 정보를 사용하여 OpenDaylight 컨트롤러에 대한 액세스를 확인할 수 있습니다.
curl -H "Content-Type:application/json" -u admin:admin http://172.17.1.18:8081/controller/nb/v2/neutron/networks
$ curl -H "Content-Type:application/json" -u admin:admin http://172.17.1.18:8081/controller/nb/v2/neutron/networks
6.2. 공급자 네트워크를 사용하여 설치 시나리오 모델링 링크 복사링크가 클립보드에 복사되었습니다!
이 설치 시나리오에서는 테넌트 네트워크 대신 공급자 네트워크를 사용한 OpenStack 및 OpenDaylight의 예를 보여줍니다. 외부 neutron 공급자 네트워크는 VM 인스턴스를 레이어-3(L3) 및 기타 네트워크 서비스를 제공하는 물리적 네트워크 인프라에 연결합니다. 대부분의 경우 공급자 네트워크는 VLAN ID를 사용하여 L2 계층(L2) 세그먼트를 구현합니다. 공급자 네트워크는 공급자 네트워크에서 VM 인스턴스 시작을 지원하는 각 컴퓨팅 노드의 공급자 브릿지에 매핑됩니다.
6.2.1. 물리적 토폴로지 링크 복사링크가 클립보드에 복사되었습니다!
이 시나리오의 토폴로지는 6개의 노드로 구성됩니다.
- x director 언더클라우드 노드 1개
- 다른 OpenStack 서비스 외에도 OpenDaylight SDN 컨트롤러가 설치된 x OpenStack overcloud 컨트롤러 3
- 두 개의 x OpenStack 오버클라우드 컴퓨팅 노드
6.2.2. 물리적 네트워크 환경 계획 링크 복사링크가 클립보드에 복사되었습니다!
오버클라우드 컨트롤러 노드는 각각 4개의 NIC(네트워크 인터페이스 카드)를 사용합니다.
| 이름 | 목적 |
|---|---|
| nic1 | 관리 네트워크(예: SSH를 통해 노드에 액세스) |
| nic2 | provisioning(PXE, DHCP), 내부 API 네트워크 |
| nic3 | 테넌트 네트워크 |
| nic4 | 공용 API 네트워크, 유동 IP 네트워크 |
오버클라우드 컴퓨팅 노드에는 네 개의 NIC가 있습니다.
| 이름 | 목적 |
|---|---|
| nic1 | 관리 네트워크 |
| nic2 | 프로비저닝 및 내부 API 네트워크 |
| nic3 | 테넌트 네트워크 |
| nic4 | 부동 IP 네트워크 |
언더클라우드 노드에는 두 개의 NIC가 제공됩니다.
| 이름 | 목적 |
|---|---|
| nic1 | 관리 네트워크에 사용 |
| nic2 | 프로비저닝 네트워크에 사용 |
6.2.3. 계획 NIC Connectivity 링크 복사링크가 클립보드에 복사되었습니다!
이 경우 환경 파일은 추상 번호가 지정된 인터페이스(nic1,nic2)를 사용하며 호스트 운영 체제(예: eth0 또는 eno 2)에 제공되는 실제 장치 이름은 아닙니다. 동일한 역할에 속하는 호스트에는 동일한 네트워크 인터페이스 장치 이름이 필요하지 않습니다. 한 호스트에서 em1 및 em2 인터페이스를 사용하는 반면 다른 호스트에서 eno1 및 eno2 를 사용하는 경우 문제가 없습니다. 각 NIC를 nic1 및 nic2 라고 합니다.
추상화된 NIC 스키마는 실시간 및 연결된 인터페이스에만 의존합니다. 호스트에 다른 수의 인터페이스가 있는 경우 호스트를 연결하는 데 필요한 최소한의 인터페이스를 사용하는 것으로 충분합니다. 예를 들어, 한 호스트에 4개의 물리적 인터페이스가 있고 다른 호스트에 6개의 물리적 인터페이스가 있는 경우 nic1,nic2,nic3, nic4 를 사용하고 두 호스트의 4개의 케이블로 연결해야합니다.
6.2.4. 네트워크, VLAN 및 IP 계획 링크 복사링크가 클립보드에 복사되었습니다!
이 시나리오에서는 네트워크 분리를 사용하여 관리, 프로비저닝, 내부 API, 테넌트, 공용 API 및 유동 IP 네트워크 트래픽을 분리합니다.
그림 6.2. 이 시나리오에서 사용되는 세부 네트워크 토폴로지
표에는 각 네트워크와 연결된 VLAN ID 및 IP 서브넷이 표시됩니다.
| 네트워크 | VLAN ID | IP Subnet |
|---|---|---|
| 프로비저닝 | 실제 하드웨어에 적용 | 192.0.5.0/24 |
| 내부 API | 600 | 172.17.0.0/24 |
| 테넌트 | 554,555-601 | 172.16.0.0/24 |
| 공용 API | 552 | 192.168.210.0/24 |
| 부동 IP | 553 | 10.35.186.146/28 |
OpenStack Platform director는 br-isolated OVS 브리지를 만들고 네트워크 구성 파일에 정의된 대로 각 네트워크의 VLAN 인터페이스를 추가합니다. director는 또한 연결된 관련 네트워크 인터페이스를 사용하여 br-ex 브릿지를 자동으로 생성합니다.
호스트 간에 연결을 제공하는 물리적 네트워크 스위치가 해당 VLAN ID 를 전달하도록 올바르게 구성되었는지 확인합니다. VLAN 을 사용하여 호스트에 있는 모든 스위치 포트를 트렁크 로 구성해야 합니다. 여기서 "trunk"라는 용어는 여러 VLAN ID 가 동일한 포트를 통과할 수 있는 포트를 설명하는 데 사용됩니다.
물리적 스위치에 대한 구성 지침은 이 문서의 범위를 벗어납니다.
network-environment.yaml 의 TenantNetworkVlanID 는 VXLAN 터널링을 사용할 때 테넌트 네트워크에 대해 VLAN 태그를 정의할 수 있습니다(예: VLAN 태그를 붙은 VLAN 태그를 통해 전송한 VXLAN 테넌트 트래픽). 테넌트 네트워크가 기본 VLAN을 통해 실행하려는 경우에도 이 값이 비어 있을 수 있습니다. 또한 VLAN 테넌트 유형 네트워크를 사용하는 경우 TenantNetworkVlanID 에 제공된 값 이외의 VLAN 태그를 사용할 수 있습니다.
6.2.5. 이 시나리오에서 사용되는 OpenDaylight 구성 파일 링크 복사링크가 클립보드에 복사되었습니다!
OpenStack 및 OpenDaylight의 이 시나리오를 배포하려면 언더클라우드 노드에 다음 배포 명령이 입력되었습니다.
이 가이드에서는 또한 이 시나리오의 구성 파일, 구성 파일 콘텐츠 및 구성에 대한 설명 정보를 보여줍니다.
6.2.5.1. extra_env.yaml 파일 링크 복사링크가 클립보드에 복사되었습니다!
파일에는 하나의 매개변수만 있습니다.
parameter_defaults:
OpenDaylightProviderMappings: 'datacentre:br-ex,tenant:br-vlan'
parameter_defaults:
OpenDaylightProviderMappings: 'datacentre:br-ex,tenant:br-vlan'
이러한 매핑은 OpenDaylight에서 제어하는 각 노드에서 사용할 매핑입니다. 물리적 네트워크 데이터 센터 는 br-ex OVS 브리지에 매핑되며 테넌트 네트워크 트래픽은 br-vlan OVS 브리지에 매핑됩니다.
6.2.5.2. undercloud.conf 파일 링크 복사링크가 클립보드에 복사되었습니다!
이 파일은 /home/stack/ 디렉터리에 있습니다.
파일 경로는 사용자 지정된 구성 파일의 버전을 가리킵니다.
이 예에서는 프로비저닝 네트워크에 192.0.5.0/24 서브넷을 사용합니다. 물리적 인터페이스 eno2 는 프로비저닝을 위해 언더클라우드 노드에서 사용됩니다.
6.2.5.3. network-environment.yaml 파일 링크 복사링크가 클립보드에 복사되었습니다!
이 파일은 네트워크를 구성하는 데 사용되는 기본 파일입니다. /home/stack/baremetal-vlan/ 디렉터리에 있습니다. 다음 파일은 다른 네트워크의 VLAN ID 및 IP 서브넷을 지정하고 공급자 매핑을 보여줍니다. nic-configs 디렉터리의 controller.yaml 및 compute.yaml 파일은 컨트롤러 및 컴퓨팅 노드의 네트워크 구성을 지정하는 데 사용됩니다.
컨트롤러 노드 (3) 및 컴퓨팅 노드(2)의 수가 예에 지정되어 있습니다.
6.2.5.4. controller.yaml 파일 링크 복사링크가 클립보드에 복사되었습니다!
이 파일은 /home/stack/baremetal-vlan/nic-configs/ 디렉터리에 있습니다. 이 예제에서는 br-isolated,br-vlan, br-ex 등의 스위치를 정의합니다. NIC2 는 br-isolated 에 있으며 nic3 는 br-ex 에 있습니다.
6.2.5.5. compute.yaml 파일 링크 복사링크가 클립보드에 복사되었습니다!
이 파일은 /home/stack/baremetal-vlan/nic-configs/ 디렉터리에 있습니다. 컴퓨팅 구성의 대부분의 옵션은 컨트롤러 구성과 동일합니다. 이 예제에서 nic4 는 외부 연결에 사용할 br-ex 아래에 있습니다(IP 네트워크 연결 )
6.2.6. 이 시나리오에서 사용되는 Red Hat OpenStack Platform director 구성 파일 링크 복사링크가 클립보드에 복사되었습니다!
6.2.6.1. neutron.conf 파일 링크 복사링크가 클립보드에 복사되었습니다!
이 파일은 /etc/neutron/ 디렉터리에 있으며 다음 정보를 포함합니다.
[DEFAULT] service_plugins=odl-router_v2,trunk
[DEFAULT]
service_plugins=odl-router_v2,trunk
6.2.6.2. ml2_conf.ini file 링크 복사링크가 클립보드에 복사되었습니다!
이 파일은 /etc/neutron/plugins/ml2/ 디렉터리에 있으며 다음 정보를 포함합니다.
-
[ml2] 섹션에서 VXLAN은 네트워크 유형으로 사용되며
opendaylight_v2메커니즘 드라이버입니다. -
[ml2_type_vlan]에서
network-environment.yaml파일에서와 동일한 매핑을 설정합니다. - [ml2_odl] 아래에 OpenDaylightController에 액세스하는 구성이 표시되어야 합니다.
이러한 세부 정보를 사용하여 OpenDaylight 컨트롤러에 대한 액세스를 확인할 수 있습니다.
curl -H "Content-Type:application/json" -u admin:admin http://172.17.1.18:8081/controller/nb/v2/neutron/networks
$ curl -H "Content-Type:application/json" -u admin:admin http://172.17.1.18:8081/controller/nb/v2/neutron/networks
7장. OpenDaylight를 통한 고가용성 및 클러스터링 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat OpenStack Platform 13은 neutron 및 OpenDaylight 컨트롤러 모두에서 고가용성 클러스터링을 지원합니다. 다음 표에서는 고가용성 클러스터를 실행하는 데 권장되는 아키텍처를 보여줍니다.
| 노드 유형 | 노드 수 | 노드 모드 |
|---|---|---|
| Neutron | 3 | 활성/활성/활성 |
| OpenDaylight | 3 | 활성/활성/활성 |
| 컴퓨팅 노드(nova 또는 OVS) | Any |
OpenDaylight 역할은 구성 가능하므로 neutron 노드와 동일한 노드에 배포하거나 별도의 노드에 배포할 수 있습니다. 설정은 all-active 설정입니다. 모든 노드는 요청을 처리할 수 있습니다. 수신 노드가 요청을 처리할 수 없는 경우 노드는 요청을 다른 적절한 노드로 전달합니다. 모든 노드는 서로 동기화를 유지합니다. OVS(Open vSwitch 데이터베이스 스키마) Southbound에서 사용 가능한 컨트롤러 노드는 Open vSwitch를 공유하므로 클러스터의 특정 노드가 각 스위치를 처리합니다.
7.1. 고가용성 및 클러스터링을 위한 OpenDaylight 구성 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat OpenStack Platform director는 OpenDaylight 컨트롤러 노드를 배포하므로 OpenDaylight에 대한 클러스터링을 구성하는 데 필요한 모든 정보가 있습니다. 각 OpenDaylight 노드에는 노드 역할 (클러스터의 이름)을 식별하는 akka.conf 구성 파일이 필요하며, 초기 노드인 클러스터의 다른 노드 중 적어도 일부를 나열합니다. 노드에는 클러스터에서 데이터가 복제되는 방법을 정의하는 module-shards.conf 파일도 필요합니다. Red Hat OpenStack Platform director는 선택한 배포 구성에 따라 올바른 설정을 수행합니다. akka.conf 파일은 노드에 따라 다르지만 module-shards.conf 파일은 노드 및 설치된 데이터 저장소(따라서 설치되는 데이터 저장소)에 따라 달라집니다.
akka.conf 파일의 예:
이 예제 노드는 시 드 노드 입니다. 현재 클러스터 설정을 전체적으로 반영할 필요가 없습니다. 시드 노드 목록을 사용하여 현재 클러스터의 실제 노드 중 하나에 연결할 수 있는 경우 시작 노드가 클러스터에 참여할 수 있습니다. 구성 파일에서 IP 주소 대신 이름을 사용할 수 있습니다.
7.2. 클러스터 동작 링크 복사링크가 클립보드에 복사되었습니다!
클러스터는 동적으로 정의되지 않으므로 자동으로 조정되지 않습니다. 새 노드만 구성하여 새 노드를 시작하고 기존 클러스터에 연결할 수 없습니다. 클러스터 관리 RPC 를 통해 노드의 추가 및 제거에 대해 클러스터에 알려야 합니다.
클러스터는 리더/Followers 모델입니다. 활성 노드 중 하나가 리더로 선택되고 나머지 활성 노드는 팔로워가 됩니다. 클러스터는 Raft 합의 기반 모델에 따라 지속성을 처리합니다. 이 원칙에 따라 클러스터의 대부분의 노드가 동의한 경우에만 트랜잭션이 커밋됩니다.
OpenDaylight에서 노드와 클러스터 연결이 끊어지면 로컬 트랜잭션이 더 이상 진행되지 않습니다. 결국 기본적으로 10분 동안 시간 초과되고 프런트 엔드 액터가 중지됩니다. 이 모든 것이 shard마다 적용되므로 다른 shard는 다른 리더를 가질 수 있습니다. 이 동작은 다음 중 하나로 이어집니다.
- 10 분 이내에 통신이 부족하면 소수의 노드가 대다수의 리더와 다시 연결됩니다. 모든 트랜잭션이 롤백되고 대부분의 트랜잭션이 재생됩니다.
- 10분 이상 통신이 없으면 소수 노드가 작동을 중지하고 해당 정보를 로그 메시지에 기록합니다. 읽기 전용 요청은 계속 완료되지만 변경 사항은 유지되지 않으며 노드는 자율적으로 클러스터에 다시 참여할 수 없습니다.
즉, 사용자가 노드를 모니터링해야 합니다. 사용자는 가용성 및 클러스터 동기화를 확인하고 동기화가 너무 긴 경우 다시 시작해야 합니다. 노드를 모니터링하기 위해 사용자는 Jolokia REST 서비스를 사용할 수 있습니다. 자세한 내용은 Monitoring with Jolokia 를 참조하십시오.
7.3. 클러스터 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
본딩 또는 MTU와 같은 클러스터를 지원하기 위한 특정 네트워킹 요구 사항은 없습니다. 클러스터 통신은 높은 대기 시간을 지원하지 않지만 데이터 검증 수준에 대기 시간이 허용됩니다.
7.4. Open vSwitch 구성 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat OpenStack Platform director는 각 스위치를 모든 컨트롤러와 자동으로 설정합니다. OVSDB는 특정 수준의 부하 분산을 허용하기 위해 클러스터 노드 간 공유 스위치를 지원합니다. 그러나 각 스위치는 클러스터의 모든 노드에 연결하여 먼저 답변하는 노드를 선택하고 기본적으로 마스터 스위치로 만듭니다. 이 동작으로 인해 노드에 가장 빠르게 응답되는 경우 대부분의 스위치를 처리할 때 컨트롤러 할당을 클러스터링할 수 있습니다.
7.5. 클러스터 모니터링 링크 복사링크가 클립보드에 복사되었습니다!
7.5.1. 모니터링 with Jolokia 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 상태를 모니터링하려면 OpenDaylight에서 Jolokia 지원을 활성화해야 합니다.
Jolokia 주소에서 구성 데이터 저장소 클러스터링 보고서를 가져옵니다.
curl -u <odl_username><odl_password>http://<odl_ip>:8081/jolokia/read/org.opendaylight.controller:type=DistributedConfigDatastore,Category=ShardManager,name=shard-manager-config
# curl -u <odl_username><odl_password>http://<odl_ip>:8081/jolokia/read/org.opendaylight.controller:type=DistributedConfigDatastore,Category=ShardManager,name=shard-manager-config
Jolokia 주소에서 운영 데이터 저장소 클러스터링 보고서를 받으십시오.
curl -u <odl_username><odl_password>http://<odl_ip>:8081/jolokia/read/org.opendaylight.controller:type=DistributedOperationalDatastore,Category=ShardManager,name=shard-manager-operational
# curl -u <odl_username><odl_password>http://<odl_ip>:8081/jolokia/read/org.opendaylight.controller:type=DistributedOperationalDatastore,Category=ShardManager,name=shard-manager-operational
보고서는 JSON 문서입니다.
사용자 환경과 일치하도록 IP 주소 와 member-1 값을 변경해야 합니다. 응답할 노드가 우선 순위가 없는 경우 IP 주소는 VIP를 가리킬 수 있습니다. 그러나 특정 컨트롤러를 주소 지정하면 더 관련성이 높은 결과를 얻을 수 있습니다.
이 설명은 각 노드에서 동일한 리더를 표시해야 합니다.
업스트림 OpenDaylight 팀에서 개발한 Cluster Monitor 툴 을 사용하여 클러스터를 모니터링할 수도 있습니다. OpenDaylight Github 저장소에서 찾을 수 있습니다.
이 툴은 Red Hat OpenStack Platform 13의 일부가 아니며 Red Hat에서 지원하거나 제공하지 않습니다.
7.6. OpenDaylight 포트 이해 링크 복사링크가 클립보드에 복사되었습니다!
모든 OpenDaylight 포트의 공식 목록은 OpenDaylight wiki 페이지에서 확인할 수 있습니다. 이 시나리오와 관련된 포트는 다음과 같습니다.
| 포트 번호 | 사용자 이름 |
|---|---|
| 2550 | 클러스터링 |
| 6653 | OpenFlow |
| 6640, 6641 | OVSDB |
| 8087 | Neutron |
| 8081 | RESTCONF, Jolokia |
컨트롤러에서 이러한 포트에 대한 트래픽을 차단하면 다음과 같은 효과가 있습니다.
- 클러스터링
- 클러스터형 노드는 통신할 수 없습니다. 클러스터형 모드로 실행할 때 각 노드에는 하나 이상의 피어가 있어야 합니다. 모든 트래픽이 차단되면 컨트롤러가 중지됩니다.
- OpenFlow
- 스위치는 컨트롤러에 도달할 수 없습니다.
- OVSDB
- Open vSwitch는 컨트롤러에 연결할 수 없습니다. 컨트롤러는 활성 OVS 연결을 시작할 수 있지만, 스위치에서 컨트롤러로 전환하는 ping이 실패하고 결국 스위치가 다른 컨트롤러로 장애됩니다.
- Neutron
- Neutron은 컨트롤러에 연결할 수 없습니다.
- RESTCONF
- REST 엔드포인트를 사용하는 외부 툴은 컨트롤러에 연결할 수 없습니다. 이 시나리오에서는 모니터링 도구에만 영향을 미칩니다.
OpenDaylight 측에서 다른 포트가 ODL 컨트롤러와 통신하는 데 사용되므로 로그에는 클러스터링에 대해 차단된 트래픽만 표시됩니다.
대상 장치에서 이러한 포트에 대한 트래픽을 차단하면 다음과 같은 효과가 있습니다.
- 클러스터링
- 클러스터형 노드는 통신할 수 없습니다. 클러스터형 모드로 실행할 때 각 노드에는 하나 이상의 피어가 있어야 합니다. 모든 트래픽이 차단되면 컨트롤러가 중지됩니다.
- OpenFlow
- 컨트롤러는 흐름을 푸시할 수 없습니다.
- OVSDB
- 컨트롤러는 스위치에 도달할 수 없습니다(컨트롤러는 패시브 OVS 연결에 응답할 수 있음).
후자의 모든 상황에서 OpenDaylight는 구성 및 운영 상태를 별도의 트리에 유지 관리하기 때문에 구성은 여전히 연결할 수 없는 장치를 가리키며 컨트롤러는 계속 연결을 시도합니다.
7.7. OpenDaylight flows 이해 링크 복사링크가 클립보드에 복사되었습니다!
| flow | 설명 |
|---|---|
| Neutron → ODL | ODL의 HA 프록시에 대한 Neutron. Pacemaker에서 VIP를 관리합니다(세 개의 백업 PIP 포함). 드라이버는 TCP 세션을 열어 두려고 시도하여 영향을 줄 수 있습니다(https://review.openstack.org/#/c/440866/). |
| ODL → Neutron | ODL-initiated 통신이 없습니다. |
| ODL → ODL | ODL 노드는 포트 2550(구성 가능)에서 서로 통신합니다. |
| ODL → OVS | ODL은 OVSDB(포트 6640 및 6641) 및 OpenFlow(포트 6633)를 사용하여 스위치와 통신합니다. VIP는 관련이 없습니다. ODL은 모든 스위치의 IP 주소를 알고 있으며 각 ODL 노드는 모든 스위치에 대해 알고 있습니다. |
| OVS → ODL | ODL은 OVSDB(포트 6640 및 6641) 및 OpenFlow(포트 6633)를 사용하여 스위치와 통신합니다. VIP는 포함되어 있지 않으며, ODL은 모든 컨트롤러를 알 수 있도록 모든 스위치를 구성합니다. 스위치에서 컨트롤러로의 알림은 모든 노드로 전송됩니다. |
7.8. Neutron DHCP 에이전트 HA 링크 복사링크가 클립보드에 복사되었습니다!
기본 설정은 OVS 에이전트와 함께 모든 neutron 노드에서 DHCP 에이전트를 실행합니다. 역할은 구성 가능하므로 에이전트가 컨트롤러와 분리할 수 있습니다. DHCP 에이전트는 포트 가져 오기 단계 및 리스 갱신 중에만 HA에 중요합니다. 포트 생성 시 neutron은 IP 및 MAC 주소를 할당하고 포트가 시작되기 전에 모든 DHCP 에이전트를 적절하게 구성합니다. 이 단계에서 모든 DHCP 에이전트가 결과 DHCP 요청에 응답합니다.
DHCP 에이전트 실패 시 데이터 플레인 가용성을 극대화하기 위해 리스가 긴 리스 시간으로 구성되고 노드는 짧은 갱신 지연으로 구성됩니다. 따라서 DHCP 에이전트는 거의 필요하지 않지만, 요청 노드에서는 사용할 수 없는 DHCP 에이전트가 빠르게 실패하고 브로드캐스트 요청을 발행하여 나머지 DHCP 에이전트를 자동으로 선택합니다.
에이전트에는 자체 프로세스 모니터가 있습니다. systemd 는 에이전트를 시작하고, 네임스페이스를 생성하고, 그 안에 프로세스를 시작합니다. 에이전트가 종료되면 네임스페이스가 그대로 유지되면 systemd 는 종료하거나 다른 프로세스를 재시작하지 않고 에이전트를 다시 시작합니다(소유하지 않음). 그런 다음 에이전트는 네임스페이스에 다시 연결하고 실행 중인 모든 프로세스와 함께 다시 사용합니다.
7.9. Neutron 메타데이터 에이전트 HA 링크 복사링크가 클립보드에 복사되었습니다!
참조 구현에서 메타데이터 서비스는 해당 DHCP 에이전트와 동일한 네임스페이스에서 네트워크 노드와 결합된 컨트롤러에서 실행됩니다. 메타데이터 프록시는 포트 80에서 수신 대기하고, 정적 경로는 잘 알려진 메타데이터 주소를 사용하여 가상 시스템에서 프록시로 트래픽을 리디렉션합니다. 프록시는 Unix 소켓을 사용하여 동일한 노드에 있는 메타데이터 서비스와 통신하고 후자는 nova와 통신합니다. Unix 소켓을 사용하면 프록시와 서비스 간에 IP를 라우팅할 수 없으므로 노드가 라우팅되지 않은 경우에도 메타데이터 서비스를 사용할 수 있습니다. HA는 유지 관리 및 VRRP 선거를 사용하여 처리됩니다. 장애 조치(failover) 시간은 2-5s입니다. 에이전트는 DHCP 에이전트와 동일한 방식으로 처리됩니다( systemd 및 네임스페이스 사용).
Red Hat OpenStack Platform 11의 메타데이터 서비스는 사용자 지정 Python 스크립트이며 Red Hat OpenStack Platform 13에서는 메모리 사용량을 30으로 낮추는 HAProxy입니다. 많은 사용자가 라우터마다 하나의 프록시를 실행하고 컨트롤러당 수천 개의 라우터가 아닌 경우 수백 개의 프록시를 실행하므로 특히 중요합니다.
8장. Red Hat OpenStack Platform 및 OpenDaylight에 대한 자세한 정보는 어디에서 찾을 수 있습니까? 링크 복사링크가 클립보드에 복사되었습니다!
| 구성 요소 | reference |
|---|---|
| OpenDaylight | 이 문서에서 다루지 않는 자세한 내용은 OpenDaylight Carbon 설명서를 참조하십시오. |
| Red Hat OpenDaylight 제품 가이드 | Red Hat OpenDaylight 및 Red Hat OpenStack Platform과 관련된 자세한 내용은 Red Hat OpenDaylight 제품 가이드를 참조하십시오. |
| Red Hat Enterprise Linux | Red Hat OpenStack Platform은 Red Hat Enterprise Linux 7.4에서 지원됩니다. Red Hat Enterprise Linux 설치에 대한 자세한 내용은 Red Hat Enterprise Linux 설치 가이드의 해당 설치 가이드를 참조하십시오. |
| Red Hat OpenStack Platform | OpenStack 구성 요소 및 해당 종속 항목을 설치하려면 Red Hat OpenStack Platform director를 사용합니다. director는 기본 OpenStack 언더클라우드를 사용합니다. 그런 다음 최종 오버클라우드에서 OpenStack 노드를 프로비저닝하고 관리하는 데 사용됩니다. 배포된 오버클라우드에 필요한 환경 외에도 언더클라우드를 설치하기 위해 하나의 추가 호스트 시스템이 필요합니다. 자세한 내용은 Director Installation and Usage 를 참조하십시오. 네트워크 격리, 스토리지 구성, SSL 통신 및 일반 설정 방법과 같은 Red Hat OpenStack Platform director를 사용하는 Red Hat OpenStack Platform 엔터프라이즈 환경에 대한 고급 기능을 구성하는 방법에 대한 자세한 내용은 Advanced Overcloud Customization 을 참조하십시오. |
| NFV 문서 | NFV를 통한 Red Hat OpenStack Platform 배포 계획에 대한 자세한 내용은 Network Functions Virtualization Planning and Configuration Guide 를 참조하십시오. |