3장. 네트워크 본딩 고려 사항


링크 집계라고도 하는 네트워크 본딩을 사용하여 여러 네트워크 인터페이스를 단일 논리 인터페이스로 결합할 수 있습니다. 즉, 네트워크 트래픽이 결합된 인터페이스에 분산되는 방법을 처리하는 데 다른 모드를 사용할 수 있습니다. 각 모드는 내결함성을 제공하며 일부 모드는 네트워크에 로드 밸런싱 기능을 제공합니다. Red Hat은 OVS(Open vSwitch) 본딩 및 커널 본딩을 지원합니다.

3.1. OVS(Open vSwitch) 본딩

OVS 본딩 구성을 사용하면 각 물리적 NIC(네트워크 인터페이스 컨트롤러)를 특정 본딩에 포트로 연결하여 단일 논리 인터페이스를 생성합니다. 이 단일 본딩은 모든 네트워크 트래픽을 처리하여 개별 인터페이스의 기능을 효과적으로 대체합니다.

OVS 인터페이스와 상호 작용하는 OVS 브릿지의 다음과 같은 아키텍처 레이아웃을 고려하십시오.

  • 네트워크 인터페이스는 브리지 미디어 액세스 제어(MAC) 주소를 사용하여 프로토콜 수준 트래픽 및 IP 주소 할당과 같은 기타 관리 작업을 관리합니다.
  • 물리적 인터페이스의 물리적 MAC 주소는 트래픽을 처리하지 않습니다.
  • OVS는 OVS 브리지 수준에서 모든 MAC 주소 관리를 처리합니다.

이 레이아웃은 본딩 인터페이스 관리가 데이터 경로 역할을 하며 OVS 브리지 수준에서 중앙 집중식 MAC 주소 관리가 수행됩니다.

OVS 본딩의 경우 active-backup 모드 또는 balance-slb 모드를 선택할 수 있습니다. 본딩 모드는 본딩 인터페이스가 네트워크 전송 중에 사용되는 방법에 대한 정책을 지정합니다.

3.1.1. 클러스터의 active-backup 모드 활성화

active-backup 모드는 기본 링크가 실패하는 백업 링크로 전환하여 네트워크 연결에 내결함성을 제공합니다.

모드는 클러스터에 대해 다음 포트를 지정합니다.

  • 하나의 물리적 인터페이스가 지정된 시간에 트래픽을 전송하고 수신하는 활성 포트입니다.
  • 다른 모든 포트가 백업 링크로 작동하고 링크 상태를 일관되게 모니터링하는 대기 포트입니다.

장애 조치 프로세스 중에 활성 포트 또는 링크가 실패하면 본딩 논리에서 모든 네트워크 트래픽을 대기 포트로 전환합니다. 이 대기 포트는 새 활성 포트가 됩니다. 페일오버가 작동하려면 본딩의 모든 포트가 동일한 MAC(Media Access Control) 주소를 공유해야 합니다.

3.1.2. 클러스터에 OVS balance-slb 모드 활성화

두 개 이상의 물리적 인터페이스가 네트워크 트래픽을 공유할 수 있도록 OVS(Open vSwitch) balance-slb 모드를 활성화할 수 있습니다. balance-slb 모드 인터페이스는 네트워크 스위치와의 로드 밸런싱 협상 없이도 가상화 워크로드를 실행하는 클러스터에 소스 로드 밸런싱(SLB) 기능을 제공할 수 있습니다.

현재 소스 로드 밸런싱은 본딩 인터페이스에서 실행되며, 여기서 인터페이스는 br-phy 와 같은 보조 브릿지에 연결됩니다. 소스 로드 밸런싱은 다양한 MAC(Media Access Control) 주소 및 VLAN(가상 로컬 영역 네트워크) 조합에서만 분산됩니다. 모든 OVN-Kubernetes Pod 트래픽은 동일한 MAC 주소와 VLAN을 사용하므로 이 트래픽을 여러 물리적 인터페이스에서 부하 분산할 수 없습니다.

다음 다이어그램에서는 간단한 클러스터 인프라 레이아웃의 balance-slb 모드를 보여줍니다. 가상 머신(VM)은 특정 localnet NetworkAttachmentDefinition (CRD) 사용자 정의 리소스 정의(CRD), CryostatD 0 또는 CryostatD 1 에 연결합니다. 각 CryostatD는 VM에 기본 물리적 네트워크에 액세스할 수 있도록 제공하여 VLAN 태그가 지정되지 않은 트래픽을 지원합니다. br-ex OVS 브리지는 VM에서 트래픽을 수신하고 트래픽을 다음 OVS 브리지 br-phy 로 전달합니다. br-phy 브리지는 SLB 본딩의 컨트롤러 역할을 합니다. SLB 본딩은 eno0eno1 과 같은 물리적 인터페이스 링크를 통해 다른 VM 포트의 트래픽을 분산합니다. 또한 물리적 인터페이스의 수신 트래픽은 OVS 브리지 집합을 통과하여 VM에 도달할 수 있습니다.

그림 3.1. 두 개의 CryostatD CRD를 사용하여 localnet에서 작동하는 OVS balance-slb 모드

두 개의 CryostatD CRD가 있는 localnet에서 작동하는 OVS 'balance-slb' 모드

OVS 본딩을 사용하여 balance-slb 모드 인터페이스를 기본 또는 보조 네트워크 유형에 통합할 수 있습니다. OVS 본딩에 대한 다음 사항에 유의하십시오.

  • OVN-Kubernetes CNI 플러그인을 지원하며 플러그인과 쉽게 통합할 수 있습니다.
  • 기본적으로 balance-slb 모드를 지원합니다.

사전 요구 사항

  • 기본 네트워크에 두 개 이상의 물리적 인터페이스가 연결되어 있으며 MachineConfig 파일에 인터페이스를 정의했습니다.
  • 매니페스트 객체를 생성하고 객체 구성 파일에서 사용자 정의 br-ex 브리지를 정의했습니다.
  • 기본 네트워크에 두 개 이상의 물리적 인터페이스가 연결되어 있으며, interfaces를 alignD CRD 파일에 정의했습니다.

프로세스

  1. 클러스터에 존재하는 각 베어 메탈 호스트의 경우 클러스터의 install-config.yaml 파일에서 다음 예와 유사한 networkConfig 섹션을 정의합니다.

    apiVersion: v1
    kind: InstallConfig
    metadata:
      name: <cluster-name>
    # ...
    networkConfig:
      interfaces:
        - name: enp1s0
          type: ethernet
          state: up
          ipv4:
            dhcp: true
            enabled: true
          ipv6:
            enabled: false
        - name: enp2s0
          type: ethernet
          state: up
          mtu: 1500
          ipv4:
            dhcp: true
            enabled: true
          ipv6:
            dhcp: true
            enabled: true
        - name: enp3s0
          type: ethernet
          state: up
          mtu: 1500
          ipv4:
            enabled: false
          ipv6:
            enabled: false
    # ...

    다음과 같습니다.

    enp1s0
    프로비저닝된 NIC(네트워크 인터페이스 컨트롤러)의 인터페이스입니다.
    enp2s0
    본딩 인터페이스에 대해 Ignition 구성 파일을 가져오는 첫 번째 본딩된 인터페이스입니다.
    mtu
    본딩 포트에서 br-ex 최대 전송 단위(MTU)를 수동으로 설정합니다.
    enp3s0
    두 번째 본딩 인터페이스는 클러스터 설치 중에 ignition을 가져오는 최소 구성의 일부입니다.
  2. NMState 구성 파일에 각 네트워크 인터페이스를 정의합니다.

    많은 네트워크 인터페이스를 정의하는 NMState 구성 파일의 예

    apiVersion: nmstate.io/v1
    kind: NodeNetworkConfigurationPolicy
    metadata:
    # ...
    ovn:
      bridge-mappings:
        - localnet: localnet-network
          bridge: br-ex
          state: present
    interfaces:
      - name: br-ex
        type: ovs-bridge
        state: up
        bridge:
          allow-extra-patch-ports: true
          port:
            - name: br-ex
            - name: patch-ex-to-phy
        ovs-db:
          external_ids:
            bridge-uplink: "patch-ex-to-phy"
      - name: br-ex
        type: ovs-interface
        state: up
        mtu: 1500
        ipv4:
          enabled: true
          dhcp: true
          auto-route-metric: 48
        ipv6:
          enabled: false
          dhcp: false
          auto-route-metric: 48
      - name: br-phy
        type: ovs-bridge
        state: up
        bridge:
          allow-extra-patch-ports: true
          port:
            - name: patch-phy-to-ex
            - name: ovs-bond
              link-aggregation:
                mode: balance-slb
                port:
                  - name: enp2s0
                  - name: enp3s0
      - name: patch-ex-to-phy
        type: ovs-interface
        state: up
        patch:
          peer: patch-phy-to-ex
      - name: patch-phy-to-ex
        type: ovs-interface
        state: up
        patch:
          peer: patch-ex-to-phy
      - name: enp1s0
        type: ethernet
        state: up
        ipv4:
          dhcp: true
          enabled: true
        ipv6:
          enabled: false
      - name: enp2s0
        type: ethernet
        state: up
        mtu: 1500
        ipv4:
          enabled: false
        ipv6:
          enabled: false
      - name: enp3s0
        type: ethernet
        state: up
        mtu: 1500
        ipv4:
          enabled: false
        ipv6:
          enabled: false
    # ...

    다음과 같습니다.

    mtu
    본딩 포트에 br-ex MTU를 수동으로 설정합니다.
  3. base64 명령을 사용하여 NMState 구성 파일의 인터페이스 콘텐츠를 인코딩합니다.

    $ base64 -w0  <nmstate_configuration>.yml

    <nmstate_configuration >: 여기서 -w0 옵션은 base64 인코딩 작업 중에 줄 래핑을 방지합니다.

  4. 마스터 역할 및 작업자 역할에 대한 MachineConfig 매니페스트 파일을 생성합니다. 이전 명령의 base64로 인코딩된 문자열을 각 MachineConfig 매니페스트 파일에 포함해야 합니다. 다음 예제 매니페스트 파일은 클러스터에 존재하는 모든 노드의 마스터 역할을 구성합니다. 노드와 관련된 마스터작업자 역할에 대한 매니페스트 파일을 생성할 수도 있습니다.

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: master
      name: 10-br-ex-master
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;charset=utf-8;base64,<base64_encoded_nmstate_configuration>
            mode: 0644
            overwrite: true
            path: /etc/nmstate/openshift/cluster.yml

    다음과 같습니다.

    name
    정책의 이름입니다.
    소스
    인코딩된 base64 정보를 지정된 경로에 씁니다.
    path
    cluster.yml 파일의 경로를 지정합니다. 클러스터의 각 노드에 대해 <node_short _hostname> .yml과 같이 노드의 짧은 호스트 이름 경로를 지정할 수 있습니다.
  5. MachineConfig 매니페스트 파일을 ./<installation_directory>/manifests 디렉터리에 저장합니다. 여기서 < installation_directory >는 설치 프로그램이 파일을 생성하는 디렉터리입니다.

    MCO(Machine Config Operator)는 각 매니페스트 파일에서 콘텐츠를 가져와 롤링 업데이트 중에 선택한 모든 노드에 지속적으로 콘텐츠를 적용합니다.

Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 문서 정보

Legal Notice

Theme

© 2026 Red Hat
맨 위로 이동