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 본딩은 eno0 및 eno1 과 같은 물리적 인터페이스 링크를 통해 다른 VM 포트의 트래픽을 분산합니다. 또한 물리적 인터페이스의 수신 트래픽은 OVS 브리지 집합을 통과하여 VM에 도달할 수 있습니다.
그림 3.1. 두 개의 CryostatD CRD를 사용하여 localnet에서 작동하는 OVS balance-slb 모드
OVS 본딩을 사용하여 balance-slb 모드 인터페이스를 기본 또는 보조 네트워크 유형에 통합할 수 있습니다. OVS 본딩에 대한 다음 사항에 유의하십시오.
- OVN-Kubernetes CNI 플러그인을 지원하며 플러그인과 쉽게 통합할 수 있습니다.
-
기본적으로
balance-slb모드를 지원합니다.
사전 요구 사항
-
기본 네트워크에 두 개 이상의 물리적 인터페이스가 연결되어 있으며
MachineConfig파일에 인터페이스를 정의했습니다. -
매니페스트 객체를 생성하고 객체 구성 파일에서 사용자 정의
br-ex브리지를 정의했습니다. - 기본 네트워크에 두 개 이상의 물리적 인터페이스가 연결되어 있으며, interfaces를 alignD CRD 파일에 정의했습니다.
프로세스
클러스터에 존재하는 각 베어 메탈 호스트의 경우 클러스터의
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을 가져오는 최소 구성의 일부입니다.
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-exMTU를 수동으로 설정합니다.
base64명령을 사용하여 NMState 구성 파일의 인터페이스 콘텐츠를 인코딩합니다.$ base64 -w0 <nmstate_configuration>.yml<nmstate_configuration>: 여기서-w0옵션은 base64 인코딩 작업 중에 줄 래핑을 방지합니다.마스터역할 및작업자역할에 대한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과 같이 노드의 짧은 호스트이름 경로를 지정할 수 있습니다.
각
MachineConfig매니페스트 파일을./<installation_directory>/manifests디렉터리에 저장합니다. 여기서 <installation_directory>는 설치 프로그램이 파일을 생성하는 디렉터리입니다.MCO(Machine Config Operator)는 각 매니페스트 파일에서 콘텐츠를 가져와 롤링 업데이트 중에 선택한 모든 노드에 지속적으로 콘텐츠를 적용합니다.