멘붕 방지: 진짜 랜카드가 죽은 걸까, 스위치가 죽은 걸까?
데이터센터로 무작정 출동하기 전에 이게 진짜 하드웨어 고장인지 선별하는 과정이 필요합니다. 랜카드 자체가 타버린 경우도 있지만, 케이블 접촉 불량이나 상단 스위치 포트 셧다운이 원인인 경우가 허다하기 때문입니다. 무작정 뜯기 전에 아래의 판별 기준을 통해 현재 상황을 냉정하게 진단해 보시기 바랍니다.
| 장애 증상 및 로그 | 의심되는 장애 원인 | 엔지니어 현장 대처법 |
|---|---|---|
| Prism Alert: NIC Link Down | 광케이블(LC) 불량 또는 SFP+ 모듈 장애 | 케이블을 뺐다 다시 꽂아보거나, 여분 케이블/모듈로 교차 테스트 진행 |
| ifconfig 상 RX/TX Error 급증 | NIC 포트 자체의 하드웨어 물리적 손상 | 포트 불량 확정. 즉시 제조사에 파츠 RMA 접수 및 교체 준비 |
| 상단 스위치 로그에 Flapping 발생 | 스위치 포트 불량 또는 LACP 협상 실패 | 네트워크 담당자와 조인하여 스위치 포트를 다른 곳으로 옮겨서 테스트 |
| AHV에서 아예 인터페이스가 안 보임 | PCIe 슬롯 인식 불가 (NIC 보드 사망) | 메인보드 슬롯 문제이거나 랜카드 완전 사망. 장비 전원 내리고 교체 필수 |
실전 교체 1단계: 사용자 VM 대피와 유지보수 모드 진입
장애 부위를 확정 지었다면 가장 먼저 할 일은 해당 노드에서 돌고 있는 소중한 사용자 VM들을 안전한 옆 노드로 대피시키는 것입니다. 무턱대고 장비를 재부팅하면 고객사 서비스가 그대로 멈춰버립니다. AHV는 이런 상황을 대비해 '유지보수 모드(Maintenance Mode)'라는 훌륭한 기능을 제공합니다. 이 기능을 켜면 노드 위에서 돌아가던 Guest VM들이 라이브 마이그레이션을 통해 서비스 끊김 없이 스르륵 다른 노드로 넘어갑니다. 동시에 CVM도 스토리지를 안전하게 내리고 대기 상태로 전환됩니다.
해당 노드의 AHV(하이퍼바이저) 쉘에 SSH로 접속한 뒤, 클러스터 스케줄러에게 이 노드를 비우겠다고 선언하기 위해 아래 명령어를 날려줍니다.
acli host.enter_maintenance_mode <문제가 발생한 Host의 IP 주소>
명령어를 치고 나면 화면에 마이그레이션 진행률이 퍼센트로 올라가는 것을
실시간으로 확인할 수 있습니다. 모든 VM이 성공적으로 넘어가면
Enter maintenance mode success라는 반가운 메시지가 툭 떨어집니다.
이때 Prism Web UI의 Hardware 탭에 들어가 보시면 해당 노드 아이콘 위에 빨간색
스패너 모양(유지보수 중) 아이콘이 예쁘게 덮어씌워진 것을 육안으로도 교차
검증할 수 있습니다.
실전 교체 2단계: 가상 스위치(OVS)에서 죽은 인터페이스 도려내기
노드가 깡통이 되었다고 바로 서버 전원을 뽑으면 안 됩니다. 현재 AHV의 브리지(보통 br0)에는 죽은 NIC(예: eth2)와 살아있는 NIC(예: eth3)가 논리적으로 묶여있는 상태입니다. 이 본딩(Bonding) 그룹에서 고장 난 인터페이스를 소프트웨어적으로 먼저 끊어주어야, 나중에 새 랜카드를 꽂고 부팅했을 때 설정 충돌이 나지 않습니다. 마치 외과 수술을 할 때 혈관을 먼저 지혈하고 장기를 떼어내는 것과 같은 이치입니다.
죽어버린 eth2를 브리지에서 깔끔하게 제거하고, 살아남은 eth3만 단독으로
남겨두기 위해 아래의 manage_ovs 명령어를 사용합니다.
manage_ovs --bridge_name br0 --interfaces eth3 update_uplinks
이 명령어를 때리면 OVS 데몬이 찰나의 순간 재시작되며, 기존 두 가닥이던 업링크
중 지정한 하나(eth3)만 활성화 상태로 구성 파일에 덮어씌워집니다. 확인을 위해
ovs-vsctl show 명령어를 쳐보시면 br0 브리지 밑에 있던 흉물스러운
eth2 포트가 마법처럼 싹 사라지고 eth3만 덩그러니 남아있는 깨끗한 상태를
확인하실 수 있습니다. 이제 논리적 적출이 끝났으니 서버 전원을 끄고 안심하고
물리적인 교체 작업을 진행하시면 됩니다.
실전 교체 3단계: 새 심장 인식시키고 클러스터 복귀하기
드디어 드라이버를 들고 서버 뚜껑을 열어 번쩍번쩍한 새 랜카드로 교체했습니다.
전원을 켜고 AHV에 다시 접속했다면, 아까 떼어냈던 과정을 역순으로 밟아줄
차례입니다. 새로 꽂은 랜카드의 물리적 인터페이스 이름(예: eth2)이 리눅스
커널에 제대로 올라왔는지 ifconfig나 ip link show로
먼저 확인하세요. 잘 보인다면 끊어놨던 혈관을 다시 이어줄 시간입니다.
새로 교체한 랜카드를 기존의 가상 브리지에 다시 묶어서 이중화 구성을 완벽하게 복원하기 위해 아래의 명령어를 때려 넣습니다.
manage_ovs --bridge_name br0 --interfaces eth2,eth3 update_uplinks
명령어 실행 후 별다른 에러 로그 없이 프롬프트가 떨어졌다면 본딩이 무사히 묶인
것입니다. 이제 allssh "manage_ovs show_uplinks" 명령어를 통해
전체 노드를 스캔해보면, 방금 작업한 노드의 br0 브리지에 eth2와 eth3가 사이좋게
active-backup(또는 셋업에 따라 balance-slb 등) 모드로 예쁘게 올라와 있는 것을
볼 수 있습니다. 이중화 검증까지 완벽하게 끝났으니, 마지막으로
acli host.exit_maintenance_mode <Host IP>를 날려서
대피시켰던 VM들을 원래 집으로 불러들이면 길었던 작업이 막을 내립니다.
현업 엔지니어가 알려주는 실무 주의사항
데이터센터 현장에서 NIC 교체할 때 제일 많이 하는 치명적인 실수가 뭔지 아십니까? 바로 '멀쩡한 옆 노드 서버의 선을 뽑아버리는 것'입니다. 랙(Rack) 뒤편으로 가면 케이블 수백 가닥이 거미줄처럼 얽혀 있어서 1번 노드와 2번 노드가 심각하게 헷갈립니다. 랜카드를 뽑기 전에 반드시 IPMI(또는 iLO)에 접속해서 UID LED(서버 앞뒤로 파란불 깜빡이는 기능)를 켜두고, 내가 작업하려는 장비가 맞는지 두 번 세 번 만져보며 확인하는 습관을 들이세요.
또 한 가지 팁이 있다면, 교체할 새 랜카드의 MAC Address를 뜯기 전에 스마트폰으로 꼭 사진을 찍어두라는 것입니다. 나중에 스위치 담당자가 "새로 끼운 랜카드 MAC 주소가 뭐예요? ARP 테이블에서 안 보이는데요?"라고 물어볼 때, 사진을 안 찍어뒀다면 무거운 서버를 랙에서 다시 꺼내서 랜카드 딱지를 들여다봐야 하는 지옥을 경험하게 됩니다.
조금이나마 보탬이 되고자 글을 쓰게 되었는데 얼마나 도움이 되었는지는 모르겠습니다. 많은 엔지니어분들에게 격려를 보냅니다
0 댓글