리눅스 네트워크 이중화 완벽 가이드: bond2team부터 RHEL 9의 nmcli 본딩까지

왜 네트워크 인터페이스를 묶어야 할까?
현대의 IT 인프라에서 서버는 비즈니스의 심장과도 같습니다. 이 심장이 멈추지 않고 안정적으로 뛰게 하려면 강력한 네트워크 연결이 필수적입니다. 하지만 단일 네트워크 케이블이나 네트워크 인터페이스 카드(NIC)에만 의존하는 것은 잠재적인 위험을 안고 가는 것과 같습니다. 이러한 단일 실패 지점(Single Point of Failure)을 제거하고 성능을 극대화하기 위해 여러 네트워크 인터페이스를 논리적으로 하나로 묶는 기술이 등장했습니다.
서버 안정성의 핵심: 네트워크 고가용성(High Availability)
자동차에 스페어 타이어가 있듯이, 서버에도 예비 네트워크 경로가 필요합니다. 만약 운영 중인 서버의 NIC 카드에 물리적 결함이 발생하거나 연결된 케이블이 뽑히는 상황을 상상해 보십시오. 단일 연결에만 의존했다면 해당 서버는 즉시 네트워크로부터 고립되어 서비스 중단으로 이어질 것입니다. 네트워크 인터페이스를 여러 개 묶어두면, 하나의 연결에 문제가 생겼을 때 시스템이 이를 자동으로 감지하고 예비 연결로 트래픽을 즉시 전환합니다. 이 과정을 '페일오버(Failover)'라고 하며, 이를 통해 서비스 연속성을 보장하고 고가용성을 달성할 수 있습니다. 이는 특히 HA 데이터베이스 클러스터나 중단 없는 서비스가 필수적인 웹 서버 환경에서 매우 중요합니다.
병목 현상 탈출: 대역폭 확장(Bandwidth Aggregation)
트래픽이 많은 도로는 차선을 확장해야 하듯, 네트워크 트래픽이 많은 서버는 더 넓은 대역폭이 필요합니다. 예를 들어, 1Gbps NIC 두 개를 논리적으로 묶으면 이론적으로 2Gbps의 대역폭을 가진 단일 채널처럼 사용할 수 있습니다. 이는 대용량 파일을 전송하는 스토리지 서버나 수많은 동시 접속을 처리해야 하는 애플리케이션 서버의 네트워크 병목 현상을 해결하는 효과적인 방법입니다. Cisco에서는 이를 'EtherChannel'이라고 부르며, 업계 전반에서 링크 집계(Link Aggregation)라는 용어로 널리 사용됩니다.
본딩(Bonding)과 티밍(Teaming) 개념 소개
리눅스 환경에서는 이러한 네트워크 고가용성과 대역폭 확장을 구현하기 위한 두 가지 주요 기술이 존재합니다: 바로 본딩(Bonding)과 티밍(Teaming)입니다. 본딩은 리눅스 커널에 오랫동안 존재해 온 전통적이고 검증된 방식이며, 티밍은 RHEL 7에서 더 나은 유연성과 관리를 목표로 도입된 현대적인 접근법입니다. 이 두 기술은 링크 집계(Link Aggregation), 포트 트렁킹(Port Trunking) 등 다양한 이름으로 불리지만, 근본적인 목표는 동일합니다.
이 글의 목표: 레거시부터 최신 RHEL 9까지의 완벽한 이해
이 글은 과거 RHEL 7/8 환경에서 본딩 설정을 티밍으로 마이그레이션하기 위해 사용되었던 bond2team
명령어부터 시작하여, RHEL 9 및 Rocky Linux 9과 같은 최신 배포판에서 nmcli
를 사용한 표준 본딩 구성 방법까지, 시대의 흐름에 따른 모든 기술적 변화를 완벽하게 이해하는 것을 목표로 합니다. 레거시 시스템을 유지보수하는 엔지니어부터 최신 인프라를 구축하는 아키텍트까지 모두에게 유용한 지침이 될 것입니다.
리눅스 네트워크 이중화의 두 기둥 - 본딩(Bonding) vs. 티밍(Teaming)
네트워크 이중화를 이해하기 위해서는 먼저 '본딩'과 '티밍'이라는 두 기술의 근본적인 차이를 알아야 합니다. 이 둘은 비슷한 목표를 가지고 있지만, 구현 방식과 철학에서 중요한 차이를 보입니다.
전통의 강자, 네트워크 본딩(Bonding) 깊이 보기
네트워크 본딩은 리눅스에서 링크 집계를 구현하는 가장 전통적이고 성숙한 방법입니다. 핵심은 모든 로직이 커널 모듈(kernel module) 형태로 커널 공간(kernel space)에서 직접 실행된다는 점입니다. 이는 하드웨어에 매우 가깝게 동작하여 높은 성능과 안정성을 제공하는 장점이 있습니다.
본딩은 다양한 '모드'를 통해 작동 방식을 결정하며, 가장 널리 사용되는 모드는 다음과 같습니다.
mode=1 (active-backup)
: 가장 간단하고 안정적인 페일오버 모드입니다. 하나의 NIC만 활성(Active) 상태로 사용하고, 다른 NIC는 대기(Backup) 상태로 있다가 활성 NIC에 문제가 생기면 즉시 트래픽을 이어받습니다. 스위치에 특별한 설정이 필요 없어 범용적으로 사용하기 좋습니다.mode=4 (802.3ad LACP)
: 진정한 의미의 링크 집계와 부하 분산을 위한 업계 표준 프로토콜입니다. 대역폭을 합치고 트래픽을 여러 링크로 분산시키기 위해 사용됩니다. 단, 이 모드를 사용하려면 연결된 스위치 역시 LACP(Link Aggregation Control Protocol)를 지원하고 관련 설정이 되어 있어야 합니다.mode=6 (balance-alb)
: 적응형 부하 분산(Adaptive Load Balancing) 모드로, 스위치의 특별한 설정 없이도 송신 및 수신 트래픽에 대한 부하 분산을 제공합니다. LACP를 사용할 수 없는 환경에서 대안으로 고려될 수 있습니다.
본딩 인터페이스의 상태는 cat /proc/net/bonding/bond0
명령어를 통해 손쉽게 확인할 수 있습니다.
유연성의 대명사, 네트워크 티밍(Teaming) 깊이 보기
네트워크 티밍은 RHEL 7에서 처음 소개된 보다 현대적인 접근법으로, 유연성과 확장성에 중점을 두고 설계되었습니다. 티밍의 가장 큰 구조적 특징은 커널과 사용자 공간의 역할을 분리한 것입니다. 실제 패킷 처리는 작은 커널 드라이버가 담당하지만, 링크 상태 감시, 페일오버 로직, 모드 구현 등 대부분의 제어 로직은 사용자 공간의 데몬 프로세스인 teamd
가 처리합니다.
이러한 구조는 다음과 같은 장점을 목표로 했습니다.
- 확장성: 커널을 직접 수정하지 않고도 사용자 공간에서 새로운 로직이나 '러너(Runner)'를 추가하기 용이합니다.
- 향상된 모니터링:
ethtool
,arp_ping
등 다양한 '링크 감시자(Link Watcher)'를 조합하여 더 빠르고 정밀하게 링크 실패를 감지할 수 있습니다. - 현대적 도구와의 통합:
teamdctl
이라는 전용 제어 유틸리티와 D-Bus API를 통해 상태를 모니터링하고 동적으로 설정을 변경하는 것이 용이합니다.
티밍의 상태는 teamdctl team0 state
명령어로 상세하게 확인할 수 있습니다.
본딩과 티밍, 핵심 차이점 전격 비교
기능 | 본딩 (Bonding) | 티밍 (Teaming) | 중요성 |
---|---|---|---|
구현 방식 | 커널 모듈 (Kernel Module) | 사용자 공간 데몬 (teamd ) + 커널 드라이버 |
안정성/성능 중심 vs. 유연성/확장성 중심의 설계 철학 차이 |
성능 | 모든 로직이 커널에서 처리되어 오버헤드가 적음 | 제어 로직은 사용자 공간, 데이터 경로는 커널에 있어 성능 저하는 거의 없다고 알려짐 | 대부분의 환경에서 체감 성능 차이는 크지 않으나, 본딩이 더 직접적인 구조 |
유연성 및 확장성 | 상대적으로 낮음 (커널 코드) | 사용자 공간 데몬 덕분에 높음 | 새로운 기능 추가나 수정 시 티밍이 더 용이하도록 설계됨 |
모니터링 | MII, ethtool 등 기본적인 링크 상태 감시 |
정교한 링크 감시자 (Link Watchers) 조합 가능 | 티밍이 더 빠르고 다양한 방법으로 장애를 감지할 수 있음 |
구성 및 제어 | (최신) nmcli , Keyfile (.nmconnection ) (레거시) ifcfg 파일, /proc 파일 시스템 |
teamdctl , nmcli , JSON 기반 설정 |
티밍은 현대적 제어 방식을 제공했으나, 본딩도 nmcli 로 통합 관리됨 |
LACP 모드 지원 | Passive 모드만 지원 | Active 및 Passive 모드 모두 지원 | 스위치 설정 환경에 따라 티밍이 더 높은 호환성을 가질 수 있었음 |
최신 동향 | 현재 표준 (Actively Maintained) | RHEL 9+ 에서 지원 중단 (Deprecated) | 미래 기술 선택의 가장 중요한 결정 요인 |
LACP 구현 방식의 결정적 차이
이론적으로 가장 중요한 차이점 중 하나는 LACP(mode=4
) 구현 방식에 있습니다. LACP 연결이 성사되려면 양쪽 장비 중 적어도 한쪽이 'Active' 모드여야 합니다. Active 모드는 먼저 LACP 제어 패킷(LACPDU)을 보내 협상을 시작하는 역할입니다. 반면 'Passive' 모드는 상대방이 보낸 LACPDU에 응답만 할 뿐 먼저 협상을 시작하지 않습니다.
전통적인 리눅스 본딩은 오직 Passive 모드만 지원합니다. 이는 본딩으로 LACP를 구성하려면, 연결되는 상대편 스위치가 반드시 Active 모드로 설정되어 있어야 함을 의미합니다. 만약 스위치도 Passive 모드로 설정되어 있다면, 양쪽 모두 서로를 기다리기만 할 뿐 LACP 연결은 절대 맺어지지 않습니다.
반면, 티밍은 Active 모드를 지원했습니다. 덕분에 스위치가 Passive 모드로 설정된 환경에서도 리눅스 서버 쪽에서 Active 모드로 동작하여 성공적으로 LACP 연결을 구성할 수 있었습니다. 이 미묘한 차이가 특정 네트워크 환경에서는 프로젝트의 성패를 가를 수도 있는 결정적인 요소였습니다.
레거시 시스템을 위한 bond2team 명령어 (RHEL 7/8 기준)
주의: 이 장에서 다루는 내용은 RHEL 7/8과 같이 ifcfg
파일을 사용하던 구형 시스템에만 해당합니다. RHEL 9, Rocky Linux 9 등 최신 시스템의 구성 방법은 5장을 참조하십시오.
이제 본딩과 티밍의 차이점을 이해했으니, 본론으로 들어가 bond2team
명령어의 사용법을 알아보겠습니다. 이 명령어는 RHEL 7이 막 도입되던 시기, 기존의 수많은 본딩 설정을 새로운 티밍 방식으로 쉽게 전환할 수 있도록 돕기 위해 탄생했습니다.
bond2team 명령어의 탄생 배경과 목적
Red Hat은 RHEL 7을 출시하며 네트워크 관리의 미래로 '티밍'을 제시했습니다. 하지만 이미 수많은 시스템이 안정적으로 '본딩'을 사용하고 있었습니다. bond2team
유틸리티는 바로 이 간극을 메우기 위한 도구였습니다. 관리자가 복잡한 티밍의 JSON 설정을 직접 작성할 필요 없이, 기존 ifcfg-bond*
파일을 분석하여 호환되는 ifcfg-team*
파일로 자동으로 변환해주는 역할을 합니다.
핵심 옵션 완벽 분석
bond2team
명령어는 여러 옵션을 제공하여 변환 과정을 제어할 수 있습니다. 주요 옵션은 다음과 같습니다.
--master <interface>
: 변환할 대상 본딩 인터페이스의 이름(예:bond0
)이나 설정 파일의 경로를 지정합니다. 가장 기본적인 필수 옵션입니다.--rename <new_name>
: 변환 후 생성될 팀 인터페이스의 새로운 이름을 지정합니다(예:team0
). 이 옵션을 사용하지 않으면 원래 이름(bond0
)을 그대로 사용하려고 시도합니다.--json
: 기본값인ifcfg
형식 대신,teamd
가 직접 사용할 수 있는 JSON 형식으로 설정을 출력합니다.--bonding_opts '<options>'
: 파일에서 설정을 읽는 대신, 커맨드라인에서 직접 본딩 옵션을 문자열로 전달하여 변환을 테스트할 수 있습니다.--outputdir <directory>
: 결과 파일을 기본 임시 디렉토리가 아닌 지정된 디렉토리에 생성합니다.--stdout
: 결과를 파일로 저장하지 않고 표준 출력(화면)으로 바로 인쇄합니다.
bond2team 주요 옵션 정리
옵션 | 설명 | 예시 |
---|---|---|
--master <interface> |
변환할 마스터 본딩 인터페이스를 지정합니다. | bond2team --master bond0 |
--rename <new_name> |
결과물인 팀 인터페이스의 이름을 변경합니다. | bond2team --master bond0 --rename team0 |
--json |
출력 형식을 ifcfg 대신 JSON으로 지정합니다. |
bond2team --master bond0 --json |
--bonding_opts '<options>' |
파일 대신 커맨드라인에서 본딩 옵션을 직접 입력받습니다. | bond2team --bonding_opts 'mode=1 miimon=100' |
--port <interface> |
팀에 포함시킬 포트 인터페이스를 지정합니다. | bond2team... --port eth1 --port eth2 |
--outputdir <directory> |
결과 파일을 저장할 디렉토리를 지정합니다. | bond2team... --outputdir /root/team_config |
--stdout |
결과를 파일이 아닌 표준 출력으로 보냅니다. | bond2team --master bond0 --stdout |
[실습] ifcfg-bond를 ifcfg-team으로 변환하기 (RHEL 7/8)
이제 실제 마이그레이션 과정을 단계별로 실습해 보겠습니다.
사전 구성 확인
먼저, 변환할 기존 본딩 설정을 확인합니다. 일반적으로 /etc/sysconfig/network-scripts/
디렉토리에 다음과 같은 파일들이 있습니다.
ifcfg-bond0
(마스터 인터페이스)DEVICE=bond0 TYPE=Bond NAME=bond0 IPADDR=192.168.1.100 NETMASK=255.255.255.0 GATEWAY=192.168.1.1 ONBOOT=yes BOOTPROTO=none BONDING_OPTS="mode=1 miimon=100"
ifcfg-enp0s8
(슬레이브 인터페이스 1)DEVICE=enp0s8 TYPE=Ethernet NAME=enp0s8 ONBOOT=yes MASTER=bond0 SLAVE=yes
ifcfg-enp0s9
(슬레이브 인터페이스 2)DEVICE=enp0s9 TYPE=Ethernet NAME=enp0s9 ONBOOT=yes MASTER=bond0 SLAVE=yes
bond2team 명령어 실행
다음 명령어를 실행하여 bond0
를 team0
라는 이름의 팀으로 변환합니다.
# bond2team --master bond0 --rename team0
명령이 성공적으로 실행되면, 결과 파일이 임시 디렉토리에 생성되었다는 메시지가 나타납니다. 이는 시스템의 실제 설정을 바로 변경하지 않는 안전장치입니다.Resulted files: /tmp/bond2team.XXXXXX/ifcfg-team0...
결과물 분석 및 적용
생성된 ifcfg-team0
, ifcfg-enp0s8
, ifcfg-enp0s9
파일의 내용을 확인하고, 기존 ifcfg
파일들을 백업한 후 새 파일들을 /etc/sysconfig/network-scripts/
로 복사합니다. 그 후 네트워크 서비스를 재시작하여 설정을 적용합니다.
변환 후 검증: teamdctl과 ping을 이용한 테스트
설정이 올바르게 적용되었는지 반드시 확인해야 합니다.
- 팀 상태 확인:
teamdctl team0 state
명령어로 팀의 상태, 러너, 포트 정보를 확인합니다. - IP 주소 및 연결 확인:
ip a
명령어로team0
인터페이스에 IP가 할당되었는지 확인하고,ping
으로 외부와의 통신을 점검합니다. - 페일오버 테스트: 실제 장애 상황을 시뮬레이션하여 고가용성이 정상 작동하는지 검증합니다.
마이그레이션 시 반드시 점검해야 할 사항 (레거시 중심)
bond2team
명령어는 편리한 도구지만, 만능은 아닙니다. 이 도구는 오직 ifcfg
파일만 수정할 뿐, 시스템의 다른 부분은 전혀 건드리지 않습니다. 이로 인해 발생할 수 있는 잠재적인 문제들을 미리 파악하고 대비하는 것이 전문가의 역량입니다.
숨겨진 복병: 방화벽(Firewall) 규칙과 라우팅 테이블
마이그레이션 후 네트워크가 먹통이 되는 가장 흔한 원인은 방화벽입니다. bond2team
은 방화벽 규칙을 자동으로 업데이트해주지 않습니다. 예를 들어, firewalld
를 사용하는 시스템에서 기존 bond0
인터페이스가 public
존(zone)에 할당되어 있었다면, 마이그레이션 후 새로 생성된 team0
인터페이스는 firewalld
의 기본 존에 할당될 수 있습니다.
해결책: 마이그레이션 전후에 firewall-cmd --get-active-zones
명령어로 인터페이스가 할당된 존을 확인하고, 필요하다면 firewall-cmd --zone=public --change-interface=team0 --permanent
명령어로 올바른 존으로 변경해야 합니다.
서비스 중단을 막는 인터페이스 이름 관리 전략
--rename
옵션은 편리하지만, 동시에 위험을 내포하고 있습니다. 만약 시스템의 다른 스크립트나 애플리케이션 설정 파일에 인터페이스 이름(bond0
)이 하드코딩되어 있다면, 이름을 바꾸는 순간 해당 서비스들은 모두 실패할 것입니다.
해결책: 마이그레이션 전에 시스템 전체에서 기존 인터페이스 이름을 참조하는 곳이 있는지 검색(grep -r "bond0" /etc/
)하고, 모든 기능이 검증된 후에 이름 변경을 진행하는 것이 안전합니다.
스크립트 및 애플리케이션 설정 호환성 확인
인터페이스 이름 변경의 영향은 생각보다 넓을 수 있습니다. 모니터링 시스템(Nagios, Zabbix 등), 백업 스크립트, 애플리케이션(Apache, Nginx 등) 설정에 인터페이스 이름이 사용된 경우, 모두 수정 대상입니다.
최신 동향 및 RHEL 9 표준 구성 (nmcli 활용)
지금까지 레거시 시스템의 마이그레이션을 다뤘습니다. 하지만 IT 기술은 끊임없이 변화하며, 현재 시점에서 가장 중요한 것은 RHEL 9(Rocky Linux 9 포함) 이후의 표준 구성 방식을 이해하는 것입니다.
티밍의 지원 중단과 본딩으로의 회귀
Red Hat은 RHEL 9부터 네트워크 티밍(teamd
)을 지원 중단(deprecated)했으며, 차기 메이저 릴리스인 RHEL 10에서는 완전히 제거될 예정이라고 발표했습니다. 그 이유는 다음과 같습니다.
- 업계 표준화 실패: 티밍은 Red Hat 생태계를 넘어서는 광범위한 업계 표준으로 자리 잡지 못했습니다.
- 개발 리소스 집중: Red Hat은 유사한 기능을 제공하는 두 기술을 동시에 유지하는 대신, 이미 널리 사용되고 커뮤니티가 활성화된 본딩 드라이버에 개발 리소스를 집중하기로 결정했습니다.
- 업스트림 프로젝트의 정체: 티밍의 핵심 라이브러리인
libteam
의 개발 활동이 줄어들면서 장기적인 유지보수에 대한 부담이 커졌습니다.
RHEL 9의 새로운 표준: ifcfg에서 Keyfile로의 전환
가장 큰 변화는 네트워크 설정 저장 방식입니다. RHEL 9부터 NetworkManager는 더 이상 /etc/sysconfig/network-scripts/
경로의 ifcfg
파일을 기본으로 사용하지 않습니다. 대신, /etc/NetworkManager/system-connections/
디렉토리에 .nmconnection
확장자를 가진 Keyfile 형식으로 설정을 저장합니다. 이 Keyfile 형식은 보다 명확하고 구조화되어 있으며, nmcli
와 같은 현대적인 도구를 통해 관리됩니다.
[실습] nmcli를 이용한 RHEL/Rocky 9 네트워크 본딩 구성
이제 RHEL 9 및 Rocky Linux 9 환경에서 표준적인 방법인 nmcli
를 사용하여 네트워크 본딩을 구성하는 방법을 단계별로 알아봅니다.
사용 가능한 네트워크 인터페이스 확인
먼저 본딩에 사용할 수 있는 인터페이스 목록을 확인합니다.
# nmcli device status
DEVICE TYPE STATE CONNECTION
ens192 ethernet connected ens192
ens224 ethernet available --
lo loopback unmanaged --
본딩 마스터 인터페이스 생성
active-backup
모드로 동작하는 bond0
인터페이스를 생성하고 고정 IP를 할당합니다.
# nmcli con add type bond con-name bond0 ifname bond0 mode active-backup ip4 192.168.1.100/24 gw4 192.168.1.1
type bond
: 연결 유형을 본드로 지정합니다.con-name bond0
: 연결 프로필의 이름을bond0
로 지정합니다.ifname bond0
: 생성될 인터페이스의 이름을bond0
로 지정합니다.mode active-backup
: 본딩 모드를 지정합니다.ip4... gw4...
: IP 주소와 게이트웨이를 설정합니다.
슬레이브 인터페이스 추가
준비된 물리 인터페이스(ens192
, ens224
)를 bond0
의 슬레이브로 추가합니다.
# nmcli con add type bond-slave con-name bond0-slave-ens192 ifname ens192 master bond0
# nmcli con add type bond-slave con-name bond0-slave-ens224 ifname ens224 master bond0
본딩 활성화 및 확인
생성된 본딩 연결을 활성화합니다.
# nmcli con up bond0
이제 /etc/NetworkManager/system-connections/
디렉토리를 확인하면 bond0.nmconnection
, bond0-slave-ens192.nmconnection
등의 파일이 생성된 것을 볼 수 있습니다.
# ls /etc/NetworkManager/system-connections/
bond0.nmconnection
bond0-slave-ens192.nmconnection
bond0-slave-ens224.nmconnection
마지막으로 본딩 상태를 확인합니다.
# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver:...
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: ens192
MII Status: up
...
Slave Interface: ens192
MII Status: up
...
Slave Interface: ens224
MII Status: up
...
Currently Active Slave
가 ens192
로 설정되어 있고, 두 슬레이브 인터페이스의 상태가 모두 up
인 것을 확인할 수 있습니다.
2024년 이후, 리눅스 네트워크 이중화를 위한 최선의 선택
그렇다면 현재 시점에서 리눅스 서버의 네트워크 이중화를 구성할 때 무엇을 선택해야 할까요?
답은 명확합니다. 모든 신규 리눅스 시스템(RHEL 9, AlmaLinux 9, Rocky Linux 9 이상)에서는 nmcli
를 사용하여 네트워크 본딩(Bonding)을 구성해야 합니다.
본딩은 다시 리눅스 네트워크 이중화의 표준으로 확고히 자리 잡았으며, 커널 커뮤니티에 의해 활발하게 유지보수되고 있습니다. 안정성, 성능, 그리고 미래 지원 측면에서 본딩은 의심의 여지 없이 가장 현명하고 안전한 선택입니다.
마무리: 현명한 네트워크 관리자를 위한 최종 요약
지금까지 리눅스의 네트워크 이중화 기술인 본딩과 티밍을 비교하고, 레거시 마이그레이션 도구인 bond2team
부터 최신 표준인 nmcli
본딩 구성까지 깊이 있게 살펴보았습니다.
bond2team의 올바른 사용처와 한계
bond2team
는 RHEL 7/8과 같은 레거시 환경에서 기존의 ifcfg
기반 본딩 설정을 티밍으로 마이그레이션해야 할 때 유용한 도구입니다. 하지만 이 도구는 설정 파일만 변환할 뿐, 방화벽이나 다른 시스템 설정은 변경하지 않으므로 사용 시 세심한 주의가 필요합니다. RHEL 9 이상의 현대적인 시스템 환경에서는 이 명령어를 사용할 이유가 없습니다.
안정성과 미래를 위한 기술 선택 가이드
기술의 흐름은 변했습니다. 한때 차세대 기술로 주목받았던 티밍은 지원 중단 수순을 밟고 있으며, 오랜 시간 검증된 본딩이 다시 표준으로 자리 잡았습니다. 따라서 모든 신규 서버 구축 및 인프라 표준화 작업에는 nmcli
를 이용한 네트워크 본딩 구성이 안정성과 장기적인 유지보수 측면에서 올바른 결정입니다.
FAQ
Q: RHEL 8에서 티밍을 사용 중인데 RHEL 9로 업그레이드하려면 어떻게 해야 하나요?
A: 업그레이드 전에 team2bond
유틸리티를 사용하여 기존 티밍 설정을 본딩 설정으로 마이그레이션하는 것을 강력히 권장합니다. RHEL 9에서는 티밍이 지원 중단되었기 때문입니다.
Q: Rocky Linux 9에서 네트워크 본딩을 구성하려면 어떤 파일을 수정해야 하나요?
A: 파일을 직접 수정하는 것은 권장되지 않습니다. 대신 nmcli
명령어를 사용하여 본딩을 구성해야 합니다. nmcli
는 /etc/NetworkManager/system-connections/
디렉토리에 .nmconnection
형식의 Keyfile을 자동으로 생성하고 관리해 줍니다.
Q: 스위치 설정 없이 사용할 수 있는 가장 간단한 이중화 모드는 무엇인가요?
A: 본딩의 mode=1 (active-backup)
모드입니다. 이 모드는 스위치에 LACP와 같은 특별한 설정 없이도 안정적인 페일오버 기능을 제공하여 고가용성을 확보할 수 있습니다.
- 블로그 : www.infracody.com
이 글이 유익했나요? 댓글로 소중한 의견을 남겨주시거나 커피 한 잔의 선물은 큰 힘이 됩니다.