[OpenStack] Network

KH55S·2025년 11월 24일
openstack
  • OpenStack에서 생성된 VM의 패킷이 물리 네트워크로 나가는 과정
[VM] 
  ↕ (연결)
[TAP Interface (tap...)]
  ↕ (연결)
[Linux Bridge (qbr...)]             <-- 여기서 Security Group(iptables) 적용
  ↕ (연결)
[VETH Pair (qvb...)]
  ↕ (Link)
[VETH Pair (qvo...)]
  ↕ (연결)
[OVS Integration Bridge (br-int)]   <-- 내부 VLAN 태깅 (Local VLAN ID)
  ↕ (Patch Port 연결)
[OVS Tunnel Bridge (br-tun)]        <-- VXLAN 캡슐화 (Global VNI)
  ↕ (연결)
[Physical Interface (eth0)]         <-- 물리 네트워크로 전송 (UDP 패킷)
  • VM 생성 : Nova가 하이퍼바이저를 통해 VM을 생성하고 Tap 인터페이스를 생성하여 VM의 가상 NIC와 호스트를 연결한다.
  • 보안 그룹(Linux Bridge) : OVS가 직접 처리하기 힘든 iptables 규칙(Security Group)을 적용하기 위해 Linux Bridge(qbr)를 생성하고 Tap 인터페이스와 연결한다.
  • VETH 연결 : qbr과 OVS(br-int)를 연결하기 위해 VETH Pair를 생성한다. qbr 쪽 끝은 qvb, br-int 쪽 끝은 qvo라고 부른다.
  • br-int : 호트스 내 모든 VM의 트래픽이 br-int로 모인다. 이때 호스트 내부에서 VM들이 속한 네트워크를 구분하기 위해 패킷에 Local VLAN ID를 태깅한다.
  • br-tun : 패킷이 다른 물리 노드로 이동해야 할 때 br-tun을 거친다.
    • Outbound : Local VLAN ID를 전역 식별자인 Global VNI로 변환하여 VXLAN 캡슐화 후 전송.
    • Inbound : 외부에서 온 패킷의 Global VNI를 Local VLAN ID로 변환하여 br-int로 전달
    • br-int와 br-tun은 Patch Port로 연결되어 속도가 빠름)

      VM의 패킷이 외부(인터넷 또는 다른 노드)로 나갈 때, br-tun 브리지에서 호스트 내부 식별자인 Local VLAN ID를 클라우드 전체 식별자인 Global VNI로 변환하여 VXLAN 캡술화를 수행하는 이유

      • VXLAN이 없다면 물리 스위치는 수천, 수만 개의 VM MAC 주소를 모두 학습해야 하므로 메모리가 부족해질 수 있다.
      • 캡슐화를 통한 은닉 : 패킷 헤더에는 물리 서버(VTEP)의 IP와 MAC 주소만 기록된다.
      • 전송 효율성 : 실제 VM의 MAC 주소는 Payload 안에 숨겨지므로, 중간 경로에 있는 물리 라우터와 스위치들은 VM의 존재를 알 필요 없이 물리 서버 간의 경로만 신경 쓰면 된다.

  • [ VM이 인터넷으로 나가려고 할 때, 패킷은 Compute Node를 떠나 Network Node에 있는 L3 Agent(Router)를 거쳐야 한다. ]
  • Compute Node에서 캡슐화된 패킷이 Network Node의 br-tun에 도착하여 역캡슐화 되어 br-int로 전달된다.
  • 라우터 네임스페이스 진입 (qr 인터페이스) : br-int에 있는 가상 라우터 역할을 하는 네트워크 인터페이스(qrouter-xxxx)가 연결되어 있다.
    • 패킷은 qr 인터페이스를 통해 OVS 영역에서 라우터 네임스페이스 내부로 들어온다.
  • 라우팅 및 NAT 수행 (iptables)
    • Routing : 네임스페이스 내부의 라우팅 테이블을 확인하여 인터넷으로 가는 경로(Default Gateway)를 찾는다.
    • SNAT : 외부와 통신하기 위해 사설 IP를 라우터의 공인 IP로 변환환다.
      • Floating IP가 없다면 : 라우터의 Gateway IP로 변환 (SNAT)
      • Floating IP가 있다면 : 1:1 매핑된 공인 IP로 변환 (DNAT/SNAT)
      • 이 작업은 네임스페이스 내부의 iptables -t nat POSTROUTING 체인에서 수행된다.
  • 외부 브리지로 전달 (qg 인터페이스) : 주소 변환이 끝난 패킷은 qg 인터페이스를 통해 네임스페이스를 빠져나와 br-ex로 전달된다.
  • 물리망 전송 : br-ex는 물리 인터페이스와 연결되어 있어, 변환된 공인 IP를 달고 실제 인터넷망으로 나간다.

Open vSwitch (OVS)

  • Linux Bridge와 OVS 차이점
  • Linux Bridge (L2 Switch)
    • 동작 원리 : MAC Learning (들어온 패킷의 소스 MAC을 보고 테이블을 채움)
    • 제어 방식 : 개입할 여지가 적음
    • 일반적인 저가형 L2 하드웨어 스위치를 소프트웨어로 옮겨놓은 것
  • Open vSwitch (SDN Switch)
    • 동작 원리 : Flow Rule (Match + Action) 기반
    • 제어 방식 : 외부 컨트롤러(Neutron 등)가 "특정 패킷은 이렇게 처리"라고 규칙(Flow)를 주입한다. MAC 주소를 학습하지 않게 설정할 수도 있고, L3/L4 헤더를 보고 라우팅을 할 수도 있다.
    • SDN(Software Defined Networking)을 구현하기 위한 핵심 데이터 플레인
  • OVS 컴포넌트
    • ovsdb-server
      • 스위치, 포트, 인터페이스 설정 정보를 저장하는 경량 데이터베이스
      • 브리지 br-int를 만들고 포트 eth0을 붙여라 같은 구성 정보가 저장된다.
    • ovs-vswitched (데몬)
      • 유저 공간에서 동작하는 데몬
      • 컨트롤러와 통신하며 Flow Rule을 받아 관리하고, 커널 모듈에 지시를 내린다.
    • Open vSwitch Kernel Module
      • 커널 공간에 있으며 실제 패킷을 처리한다.
      • 메모리에 캐시된 Flow Rule이 있다면, 유저 공간까지 가지 않고 커널에서 즉시 패킷을 처리하여 성능을 극대화한다.
  • Flow
    • OVS의 모든 동작은 Flow Table에 적힌 규칙에 따른다. 하나의 규칙은 다음과 같이 구성된다.
      • Priority : 여러 규칙이 매칭될 때 숫자가 높은 규칙을 먼저 적용
      • Match Fields (조건)
      • Action (동작)
  • OVS 정리
    • OpenStack Neutron 네트워크의 데이터 플레인을 담당하는 SDN 기반의 고성능 가상 스위치
    • 특징
      • 프로그래머블 : 단순한 L2 스위치(MAC 학습)와 달리, 중앙 컨트롤러인 Neutron의 지시에 따라 Flow Rule을 통해 패킷을 정교하게 제어, 변조, 차단한다.
      • 터널링 지원 : 소프트웨어적으로 VXLAN, GRE 캡슐화 및 역캡슐화를 수행하여, 물리 네트워크 위에서 가장 L2 네트워크를 구현한다.
      • 유연한 구조 : br-int, br-tun 등 여러 브리지를 연결하여 VLAN 태깅 및 변환 작업을 수행함으로써 멀티 테넌시 환경을 지원한다.

        멀티 테넌시
        하나의 하드웨어나 소프트웨어 인스턴스를 여러 사용자 그룹(Tenant)이 공유하여 사용하지만, 논리적으로 완벽하에게 격리되어 마치 자신들만 해당 자원을 독점해서 쓰는 것처럼 느끼게 하는 환경

        • CPU, 메모리, 스토리 등 비싼 물리적 자원은 효율성을 위해 공유하지만, 데이터, 네트워크 트래픽, 사용자 설정 등은 철저히 분리되어, 테넌트A는 테넌트B의 존재조차 알 수 없어야 한다.

WHY?

  • Q. VXLAN를 사용하는 이유 중 하나는 물리 스위치가 모든 VM들의 MAC 주소 학습을 막기 위함이다. 그렇다면 이때 VM의 MAC 주소를 학습해야 하는 물리 스위치는 무엇일까?
  • A. 서버와 물리적으로 직접 연결된 첫 번째 스위치인 ToR 스위치
  • ToR (Top of Rack) 스위치
    • ToR : 서버실 랙 최상단에 해당 렉에 꽂힌 물리 서버들의 랜선을 받아주는 스위치
    • VM이 패킷을 보내면, 이 패킷이 물리 서버의 랜카드를 떠나 가장 먼저 도착하는 장비가 ToR 스위치이다. 따라서, 가장 먼저, 반드시 VM의 MAC을 학습해야 하는 장비이다.
  • VXLAN이 없으면 패킷의 Source MAC은 VM의 가상 MAC 주소가 되고, 물리 서버의 랜카드와 케이블을 통해 ToR 스위치의 특정 포트(1번)로 패킷이 들어가게 된다.
    • 이때, ToR 스위치는 헤더를 까보고 Source MAC을 확인해보는데, 여기에는 VM의 MAC주소가 적혀 있다.
    • 스위치는 자신의 메모리에 MAC Address: fa:16:3e:aa:bb:cc | Port: 1 | VLAN: 10와 같이 기록하여 fa..이라는 컴퓨터는 1번 포트에 연결된 서버에 존재한다고 학습한다.
    • 만약 서버 1대 당 VM이 100개 있고, 서버가 20대가 있으면, ToR 스위치 하나가 학습해야 하는 MAC 주소는 2000개 된다.
profile
KH55S
이전 포스트

[📌] Linux & Network

다음 포스트

Terraform 기본

0개의 댓글