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

OVN 아키텍처는 다음 구성 요소 및 서비스로 구성됩니다.

ovn-controller 서비스는 각 컴퓨팅 노드에서 실행되며 OVN southbound(SB) 데이터베이스 서버에 연결하여 논리 흐름을 검색합니다. ovn-controller 는 이러한 논리 흐름을 물리적 OpenFlow 흐름으로 변환하고 OVS 브리지(br-int)에 흐름을 추가합니다. ovs-vswitchd 와 통신하고 OpenFlow 흐름을 설치하기 위해 ovn-controller 는 ovn-controller 가 시작될 때 전달된 UNIX 소켓 경로를 사용하여 로컬 ovsdb-server (호스트 conf.db)에 연결합니다(예: unix:/var/run/openvswitch/db.sock).

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

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

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

기본 RHOSP ML2/OVN 배포에서 ML2/OVNable 서비스는 컨트롤러 노드에서 실행됩니다. 선택적으로 사용자 지정 Networker 역할을 생성하고 전용 Networker 노드에서 OVN 구성 가능 서비스를 실행할 수 있습니다.

OVN 구성 가능 서비스 ovn-dbs -bundle은 ovn-dbs-bundle이라는 컨테이너에 배포됩니다. 기본 설치 ovn-dbs 는 컨트롤러 역할에 포함되어 있으며 컨트롤러 노드에서 실행됩니다. 서비스는 구성 가능하므로 Networker 역할과 같은 다른 역할에 할당할 수 있습니다.

OVN 구성 가능 서비스를 다른 역할에 할당하는 경우 서비스가 pacemaker 서비스와 동일한 노드에 배치되어 OVN 데이터베이스 컨테이너를 제어하는지 확인합니다.

기본 RHOSP ML2/OVN 배포에서 ML2/OVNable 서비스는 컨트롤러 노드에서 실행됩니다. 전용 네트워크 노드에서 OVN 구성 가능 서비스를 실행하는 Networker와 같은 지원되는 사용자 지정 역할을 선택적으로 사용할 수 있습니다.

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

기본 프로필인 ovn-dbs -container 및 pacemaker 고가용성(HA) 프로필인 ovn-dbs-container-puppet 중 하나를 선택할 수 있습니다.

pacemaker HA 프로필이 활성화된 상태에서 ovsdb-server 는 pacemaker 및 리소스 에이전트 Open Cluster Framework(OCF) 스크립트에서 관리하는 마스터-슬레이브 모드로 실행됩니다. OVN 데이터베이스 서버는 모든 컨트롤러에서 시작하고 pacemaker 에서 마스터 역할에 제공할 컨트롤러 1개를 선택합니다. master 모드에서 실행되는 ovsdb-server 인스턴스는 데이터베이스에 쓸 수 있지만 다른 모든 slave ovsdb-server 서비스는 마스터에서 데이터베이스를 로컬로 복제하고 데이터베이스에 쓸 수 없습니다.

이 프로필의 YAML 파일은 tripleo-heat-templates/environments/services-docker/neutron-ovn-dvr-ha.yaml 파일입니다. 활성화된 경우 OVN 데이터베이스 서버는 Pacemaker에서 관리하며 puppet-tripleo 는 ovn:ovndb-servers 라는 Pacemaker OCF 리소스를 생성합니다.

OVN 데이터베이스 서버는 각 컨트롤러 노드에서 시작되며 가상 IP 주소(OVN_DBS_VIP)를 소유하는 컨트롤러에서 마스터 모드에서 OVN DB 서버를 실행합니다. OVN ML2 메커니즘 드라이버 및 ovn-controller 는 OVN_DBS_VIP 값을 사용하여 데이터베이스 서버에 연결합니다. 장애 조치(failover)가 발생하면 Pacemaker에서 가상 IP 주소(OVN_DBS_VIP)를 다른 컨트롤러로 이동하고 해당 노드에서 실행되는 OVN 데이터베이스 서버를 마스터 로 승격합니다.

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

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

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

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

ML2/OVN 배포에서 DVR(분산 가상 라우팅)을 배포하고 관리하려면 heat 템플릿 및 환경 파일에서 설정을 구성합니다.

기본 설정은 지침으로만 제공됩니다. 네트워크 격리, 전용 NIC 또는 기타 여러 변수 요인에 대한 사용자 지정이 필요할 수 있는 프로덕션 또는 테스트 환경에서는 작동하지 않습니다.

다음 예제 절차에서는 일반적인 기본값을 사용하여 ML2/OVN, HA, DVR의 개념 증명 배포를 구성하는 방법을 보여줍니다.

OVN 메타데이터 에이전트는 tripleo-heat-templates/docker/services/ovn-metadata.yaml 파일에 구성되며 OS::TripleO::Services::OVNMetadataAgent 를 통해 기본 Compute 역할에 포함됩니다. 따라서 기본 매개변수가 있는 OVN 메타데이터 에이전트는 OVN 배포의 일부로 배포됩니다. 3장. director를 사용하여 OVN 배포 을 참조하십시오.

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

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

# ip netns exec ovnmeta-fd706b96-a591-409e-83be-33caea824114 ssh USER@INSTANCE_IP_ADDRESS

east-west 트래픽에 대해 로컬 네트워크에서 IP 주소 대신 도메인 이름을 사용하려면 내부 도메인 이름 서비스(DNS)를 사용합니다. 내부 DNS를 사용하면 ovn-controller가 계산 노드에서 로컬로 DNS 쿼리에 응답합니다. 내부 DNS는 인스턴스의 /etc/resolv.conf 파일에 지정된 모든 사용자 지정 DNS 서버를 재정의합니다. 내부 DNS를 배포하면 인스턴스의 DNS 쿼리는 사용자 지정 DNS 서버 대신 ovn-controller에서 처리합니다.

OVN 데이터베이스 명령(예: ovn-nbctl show)은 ovn_controller 컨테이너에서 실행됩니다. 컨테이너는 컨트롤러 노드 및 계산 노드에서 실행됩니다. 명령에 대한 액세스를 단순화하려면 별칭을 정의하는 스크립트를 생성하고 소싱합니다.

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

$ ovn-sbctl --db=tcp:172.17.1.10:6642 lflow-list
    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의 주요 차이점은 다음과 같습니다.

이 예에서는 시뮬레이션된 패킷의 --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'
# 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 "" */;
    };
};

예제 출력에는 다음이 표시됩니다.

자세한 내용은 ovn-trace man 페이지를 참조하십시오.

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

$ 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