Nutanix AHV 실무: 식은땀 흐르는 Active-Standby에서 LACP로의 전환기

오늘은 Nutanix 네트워크 변경작업에 대해 알아보도록 하겠습니다.  고객사에서 많이 하는 작업은 아니지만, 피할 수 없는 작업인데요. 작업 전 체크사항 및 유의사항에 알아보도록 하죠. 경어체는 생략합니다.

멀쩡한 Active-Standby 놔두고 왜 LACP로 가려는 걸까?

현장에서 일하다 보면 고객사가 갑자기 네트워크 구성을 엎어달라고 요청하는 경우가 꽤 잦다. 이번 건도 비슷했다. 잘 돌아가고 있는 무난한 Active-Standby 환경을 굳이 LACP(Link Aggregation Control Protocol)로 변경해 달라는 거다. 이유는 뻔하다. 대역폭을 최대한 끌어다 쓰고 싶고, 이중화 구성 시 놀고 있는 대기(Standby) 포트가 아깝게 느껴지기 때문이다. 요구사항은 단순하지만 이 작업을 직접 수행해야 하는 엔지니어 입장에서는 등골이 서늘해지는 미션이다. 관리 IP가 통신하는 브릿지의 설정을 실시간으로 건드려야 하는데, 중간에 스위치와 LACP 협상이 한 끗이라도 어긋나면 호스트가 통째로 네트워크에서 고립되어 버린다. CVM(Controller VM) 통신이 끊어지면 클러스터 전체의 안정성에도 치명타를 입힐 수 있다. 주니어 엔지니어들이 가장 많이 실수하고 장애를 내는 구간이기도 하다. 오늘 이 글에서는 단순 공식 매뉴얼에는 절대 안 나오는, 실제 작업 시 주의해야 할 변수들과 명령어의 진짜 의미를 하나씩 뜯어보겠다.

작업 전 생존 체크리스트: 스위치 담당자 멱살 잡기 전에 확인할 것

무턱대고 콘솔부터 여는 건 하수나 하는 짓이다. 양단 네트워크를 묶는 작업인 만큼, 호스트를 건드리기 전에 인프라 환경이 작업 가능한 상태인지 명확히 짚고 넘어가야 피를 보지 않는다.

• AOS 버전 확인: 5.15 버전을 기점으로 Virtual Switch(VS) 아키텍처가 강제 적용되었기 때문에, 버전에 따라 명령어 진입로 자체가 완전히 다르다.
• 상단 스위치 LACP 모드(Active vs Passive): AHV는 기본적으로 LACP 협상을 적극적으로 시도하려 하므로, 스위치 쪽 LACP 모드가 반드시 'Active'로 설정되어 있는지 담당자에게 다짐을 받아내야 한다.
• IPMI/AHA(Out-of-band) 접속 확보: 호스트가 네트워크에서 미아 상태가 되었을 때 살릴 수 있는 유일한 동아줄이다. KVM 콘솔 접속이 원활한지 창을 미리 띄워놔라.

LACP 구성 작업 개요

위 구성도처럼 호스트의 물리 NIC 두 개를 스위치와 LACP로 묶어 하나의 논리적 파이프로 만들어야 한다. 대역폭 확장의 장점은 크지만, 그만큼 스위치와 호스트 양단의 설정 타이밍이 생명이다.

 

무덤을 피하는 첫 단추: Virtual Switch(VS)부터 깔끔하게 밀어라

AHV 네트워크 설정에 들어가기 전, 가장 먼저 확인해야 할 무덤 같은 함정이 하나 있다. 앞서 언급한 AOS 5.15 이후부터 도입된 Virtual Switch(VS) 기능이다. 기존 브릿지(br0) 기반 설정 위에 VS가 껍데기처럼 올라타 있는 상태다. 이 사실을 모른 채 무턱대고 예전 방식의 OVS(Open vSwitch) 명령어를 브릿지에 때려 넣으면 설정이 무참히 꼬여버리고 클러스터 통신이 마비된다. 안전하게 알맹이(br0)를 꺼내서 작업하기 위해 아래 명령어 라인을 실행해야 한다.

acli net.disable_virtual_switch
acli net.migrate_br_to_virtual_switch br0 vs_name=vs0

이 두 줄의 명령어를 그냥 기계적으로 복사해서 붙여넣고 끝낼 생각은 버려라. 첫 번째 명령어인 disable_virtual_switch는 현재 덮어씌워진 VS 구성을 일시적으로 비활성화하여 우리가 OVS 레벨의 기본 브릿지(br0)에 직접 접근할 수 있도록 길을 열어주는 핵심 열쇠다. 이걸 빼먹으면 뒤에서 아무리 본딩 모드를 바꿔도 시스템이 먹어주질 않는다는 사실. 두 번째 migrate 명령어는 당신이 LACP 설정을 비롯한 모든 OVS 하위 작업을 완벽하게 끝낸 후 쳐야 하는 '복원 구문'이다. 이 명령을 통해 날것의 br0 브릿지를 다시 vs0라는 가상 스위치 환경으로 안전하게 편입시킨다. 이 두 가지 절차로 기존 네트워크를 샌드위치처럼 감싸고 작업해야만 중간에 핑이 끊겨서 콘솔 들고 서버실로 뛰어가는 대참사를 막을 수 있다.

 

실전 LACP 설정: 파라미터 하나가 퇴근 시간을 결정한다

길이 열렸으니 본격적으로 호스트에 LACP를 먹일 차례다. 옛날 방식처럼 `ovs-vsctl` 명령어로 포트 단위 설정을 하나씩 쪼개서 넣을 수도 있다. 하지만 현장에서는 휴먼 에러를 극단적으로 줄이고 롤백을 편하게 하기 위해 `manage_ovs` 스크립트를 한 줄로 실행하는 것을 강하게 권장한다. 타이핑 오타 한 번이 호스트 다운으로 직결되는 살 떨리는 상황에서, 스크립트를 통한 일괄 적용은 엔지니어의 수명을 십 년은 늘려준다.

manage_ovs --bridge br0 --interfaces eth2,eth3 --bond_name br0-up --host hh.hh.hh.hh --bond_mode balance-tcp --lacp_mode fast --lacp_fallback true update_uplinks require_link=false

이 명령어 한 줄에 오늘 작업의 성패가 달려있다. 각 파라미터가 시스템 내부에서 어떤 동작을 일으키는지 뼛속까지 이해해야 장애 시 대처가 가능하다. 먼저 `--bond_mode balance-tcp`는 패킷을 단순히 목적지 MAC 주소 기반으로 뭉툭하게 쪼개는 게 아니라, L4 계층의 세션 단위로 아주 정교하게 로드밸런싱을 치겠다는 선언이다. 이게 들어가야 비로소 LACP를 구성하는 진짜 목적인 '대역폭 분산'을 달성할 수 있다. 그다음 `--lacp_mode fast` 옵션을 주목해라. 기본값은 slow(30초)로 잡혀있는데, 이를 fast로 쥐어짜면 1초 단위로 상대방 스위치와 LACP DU(데이터그램) 심장 박동을 교환한다. 물리 스위치 포트에 순식간에 장애가 났을 때 트래픽을 30초 동안 허공에 날려버릴 것인가, 아니면 3초 안에 살아있는 포트로 절체시킬 것인가를 결정짓는 아주 무서운 설정이다. 마지막으로 `--lacp_fallback true`와 `require_link=false`는 절벽에서 당신을 살려줄 생명줄 그 자체다. 스위치 쪽에서 아직 LACP 포트채널 설정이 안 끝났거나 구성이 살짝 틀어졌을 때 호스트가 통신을 포기하지 않게 만든다. '아, 스위치가 아직 LACP를 못 알아먹네? 일단 임시로 Active-Standby로 동작해서 통신은 살려둘게'라고 판단하게 만드는 유일한 안전장치다. 이 옵션 없이 작업하다 양단 싱크가 단 1초라도 어긋나면 호스트는 즉시 관리망에서 사라지고 장애 경보가 울리기 시작한다.

실무에서 주의할 점: 상단 스위치 담당자와의 피 말리는 눈치싸움 현장에서는 호스트 터미널에서 엔터 키를 치기 직전에 상단 스위치 담당자에게 "지금 포트채널 올립니다. 확인해주세요!"라고 육성으로 싸인을 맞춰야 한다. 스위치 쪽에 LACP 적용이 미진한 상태에서 AHV 쪽에만 적용이 들어가면 아무리 fallback 옵션이 있다 하더라도 일시적인 핑 단절이나 네트워크가 붙었다 떨어졌다를 반복하는 플래핑(Flapping) 현상이 발생해 가상머신(VM)들의 세션이 모조리 끊어질 수 있다.

 

살 떨리는 검증 타임: 'negotiated'를 확인하기 전까진 숨도 쉬지 마라

터미널에 명령어가 에러 줄 없이 깔끔하게 떨어졌다고 끝난 게 아니다. 에러 메시지가 없다고 해서 실제로 스위치 양단에서 패킷이 정상적으로 쪼개져 넘어가고 있다는 뜻은 아니기 때문이다. 네트워크 작업은 검증 명령어를 통해 현재 상태를 내 두 눈으로 직접 확인해야만 비로소 끝이 난다. 추측으로 작업 완료 보고를 했다가는 다음 날 아침 엄청난 전화를 받게 될 것이다. 후, 스트레스 ~ 

ovs-appctl bond/show br0-up 

이 짧은 명령어를 치면 현재 브릿지 업링크의 심장부 상태가 주르륵 쏟아진다. 여기서 제일 먼저, 그리고 가장 뚫어져라 쳐다봐야 할 항목은 단연코 `lacp_status` 값이다. 이 값이 반드시 **negotiated**로 떨어져 있어야 오늘 다리 뻗고 편히 잘 수 있다. 이는 호스트와 스위치가 서로 완벽하게 LACP 프로토콜을 주고받으며 합의를 끝냈다는 의미다. 만약 이 부분이 **configured**라고 출력되어 있다면 심각한 상황이다. 호스트 설정 자체는 장비에 들어갔지만 상대편 물리 스위치와 전혀 대화가 안 돼서 LACP가 사실상 빈껍데기 상태로 죽어있다는 뜻. 이때는 당황하지 말고 즉시 스위치 담당자를 호출해서 LACP 모드가 제대로 active 상태인지, 인터페이스가 vPC나 MLAG 설정에 정상적으로 묶여있는지 더블 체크를 요구해야 한다. 아울러 하단에 출력되는 slave eth2와 eth3의 상태를 보면서 `hash load` 값들이 양쪽 인터페이스에 몇 kB씩 골고루 분산되어 찍히고 있는지도 꼼꼼히 체크해라. 트래픽 해시값이 한쪽 인터페이스에만 비정상적으로 쏠려있다면 balance-tcp 로드밸런싱이 제대로 작동하지 않는 반쪽짜리 LACP다.

크로스 체크를 위한 방어 운전 꿀팁

한 번의 검증으로는 불안하다. 네트워크가 살아있는지 교차로 검증하여 내 작업의 무결성을 입증해야 한다.

ovs-appctl lacp/show br0-up

위 명령어를 덧붙여 실행해라. 전역 상태가 `status: active` 상태로 명확히 올라와 있는지 살피고, 스위치와 물리적으로 묶여있는 개별 슬레이브 인터페이스들이 모두 `current attached` 상태로 짱짱하게 붙어있는지 확인필수! 이 두 가지가 모두 완벽해야 진정한 LACP 구성 완료다. 

negotiated 확인 모습

사진처럼 negotiated가 선명하게 뜨고, 아래 두 개의 슬레이브 인터페이스 해시값이 골고루 춤을 추며 분배되고 있어야 비로소 닫혀있던 식도의 숨통이 트이며 커피 한 잔을 마실 여유가 생긴다.

 

장애 발생 시 생명줄: 빛의 속도로 Active-Standby 롤백하기

IT 인프라 실무에서 '100% 완벽한 작업'이라는 단어는 존재하지 않는다. 스위치 펌웨어 버그로 인한 호환성 문제든, 작업자의 순간적인 설정 오타든 네트워크가 꼬이는 순간은 예고 없이 찾아온다. 클러스터 관리 페이지에 빨간색 알람이 뜨고 CVM 접속이 튕기기 시작하면 고민하지 말고 즉시 원래의 Active-Standby 상태로 롤백해야 한다. 원인을 찾겠다고 로그를 뒤적거릴 시간이 없다.

manage_ovs --bridge br0 --interfaces eth2,eth3 --bond_name br0-up --host hh.hh.hh.hh --bond_mode active-backup --require_link=false update_uplinks

이 롤백 명령어는 무슨 일이 있어도 당신의 바탕화면 작업 노트 최상단에 고이 적어두고 시작하길,, `bond_mode`를 가장 보수적이고 안전한 `active-backup`으로 되돌리고, 지금껏 꼬여버린 LACP 구성을 강제로 무력화시키는 구문이다. 마찬가지로 쉘에서 `manage_ovs` 스크립트가 도저히 먹히지 않는 최악의 상황이라면 원시 명령어로 직접 롤백해야 한다. `bond_mode=activebackup`, `lacp=off`, `other_config:lacp-fallback-ab=False` 이 세 가지 파라미터를 `ovs-vsctl set port` 명령을 통해 br0-up 포트에 억지로 쑤셔 넣으면 구성이 원래대로 풀린다. 장애가 나면 뒤통수가 뜨거워지고 머리가 하얘져서 평소 안 하던 오타가 나기 십상이다. 반드시 작업 시작 며칠 전부터 미리 롤백 스크립트를 완벽하게 텍스트로 준비해 두고, 호스트 IP 변수만 바꿔서 바로 마우스 우클릭으로 붙여넣기 할 수 있도록 세팅해 두는 것이 선배들이 숱한 철야와 시말서를 통해 얻은 진짜 생존 노하우ㅋㅋㅋ

AHV 업링크 구성 비교: Active-Standby vs LACP

구분	Active-Standby (Active-Backup)	LACP (Balance-TCP)
대역폭 활용	1개 물리 포트만 통신 활성화 (나머지는 놀고 있는 대기 상태)	묶인 모든 물리 포트의 대역폭을 논리적으로 합산하여 100% 사용
설정 난이도	매우 쉬움 (스위치 쪽에 특별한 포트채널 설정이 불필요함)	매우 까다로움 (스위치 양단 설정 일치 및 작업 타이밍 맞추기 필수)
실무 장애 포인트	거의 없음 (안정성과 롤백 용이성 최상)	LACP 협상 실패 시 완전한 통신 단절 위험, Fallback 안전장치 누락 시 치명적

이렇게 힘든 네트워크 작업이 끝나고, Active-Standby vs LACP 정리를 하면 나중에 헷갈리지도 않고 도 똑같은 작업을 할때도 무난하게 작업 할 수 있게 됩니다.  꼭 어떤 작업이든 정리하는 습관을 가지세요. 그럼 이만 마칠께요.