OCe14000 LoM, 케이블을 뽑아도 link up이라고 보고해서 ESXi 티밍이 페일오버를 안 함
소규모 vSphere 클러스터고, 호스트당 10G 업링크 두 개가 ToR 스위치 한 쌍에 물려 있습니다. 펌웨어 업데이트 때문에 ToR을 재부팅한 뒤, 한 호스트의 VM 일부가 먹통이 됐고 vMotion도 양쪽 업링크 모두 실패했습니다. 그런데 ESXi는 아무것도 down으로 표시하지 않았고 어댑터 LED도 내내 켜져 있었습니다.
- Fujitsu Primergy RX2540 M1
- Emulex OneConnect OCe14000 LAN-on-motherboard 어댑터(VID 10df DID 0720 SVID 1734 SSID 120e)
- ESXi 6.0 U3
- ToR로 들어가는 SFP+ 옵틱, vSwitch에 일반 active/standby 티밍
이게 스위치 문제가 아니라고 확신하게 된 계기는, 어댑터에서 광케이블을 완전히 뽑았는데도 여전히 살아있는 것처럼 보인다는 겁니다.
esxcli network nic get -n vmnic2 (cable physically removed)
Link Status: Up
Firmware Version: 11.2.1194.36
esxcli software vib list | grep elxnet
elxnet 10.2.309.6v이미 해본 것:
- 옵틱과 광케이블 재장착, 패치 리드 교체
- 업링크를 다른 ToR 스위치로 이동, 그쪽 포트는 예상대로 down됨
- 호스트의 관리 에이전트 재시작
호스트가 업링크가 살아있다고 믿고 있으니 티밍 정책은 아무것도 옮길 이유가 없고, VM들은 죽은 포트에 계속 묶여 있습니다. 이거 OneConnect에서 알려진 드라이버 대 펌웨어 문제인가요, 아니면 LoM 하드웨어를 봐야 하나요?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 6
그 조합이 문제의 원인이고, ESXi 6.0에서 지원되는 페어링으로 등재돼 있지 않습니다. 어댑터가 반쯤만 살아있는 상태가 된 겁니다. 트래픽은 더 이상 안 움직이는데 포트는 계속 connected로 광고하니까, 티밍 정책이 동작하는 데 필요한 down 이벤트를 절대 못 받는 거죠. 그래서 정직한 NIC 고장 대신 양쪽 업링크 모두 vMotion이 죽은 부분 격리 상태로 드러난 겁니다. 제대로 죽는 카드가 거짓말하는 카드보다 훨씬 버티기 쉽습니다.
드라이버를 11.2.1149.0으로 올리세요. VMware 호환성 목록에서 펌웨어 11.2.1194.36에 맞춰 검증된 elxnet 레벨이 그겁니다. 그러니까 카드를 되돌리는 게 아니라 드라이버를 펌웨어에 맞추는 쪽으로 옮기는 겁니다. 그다음엔 이미 갖고 계신 명령 두 개로 확인하세요.
vib 줄에는 새 버전이 보여야 하고, 호스트가 다시 올라오면 Link Status도 다시 케이블을 따라가야 합니다. 클러스터를 믿고 맡기기 전에 그 업링크에 VM을 하나 돌려놓고 광케이블을 뽑아서 테스트해보세요.
챙겨갈 만한 습관이 있습니다. OneConnect에서는 드라이버랑 펌웨어가 페어로 움직이니까, 유지보수 번들이 둘 중 하나만 혼자 끌고 가게 두지 말고 둘을 같이 스케줄하세요. 이 두 줄을 비교하는 건 명령 하나면 되고, 옵틱을 뽑거나 스위치를 탓하기 훨씬 전에 해야 할 일입니다.
올려주신 두 줄이 흥미로운 부분입니다. elxnet 10.2.309.6v 밑에서 펌웨어 11.2.1194.36이 돌고 있다는 거요. 그 펌웨어가 드라이버랑 별도로 언젠가 서버 유지보수 번들로 들어온 건가요?
그 페어링을 "최신이면 당연히 괜찮겠지"가 아니라 ESXi 6.0 호환성 목록에 대조해서 확인하세요. OneConnect는 드라이버와 펌웨어가 페어로 검증되는 계열 중 하나고, 안 맞는 페어가 꼭 요란하게 실패하는 것도 아닙니다. 반쯤 동작하는데, 그게 훨씬 나쁩니다.
어댑터의 두 번째 포트도 케이블을 뽑았을 때 똑같이 동작하는지도 말씀해주시면 좋겠네요.
네, 펌웨어는 서버 유지보수 번들로 들어왔고, 드라이버는 호스트를 처음 구성한 뒤로 손댄 적이 없습니다.
LoM 포트 둘 다 똑같이 동작합니다. 케이블을 뽑아도 esxcli network nic get은 여전히 Link Status: Up을 보고하고, LED도 계속 켜져 있고, vSwitch는 업링크를 active 목록에 계속 남겨둡니다. 스위치 쪽은 깨끗하고 뽑는 순간 그쪽 포트는 바로 떨어집니다.
그러니까 이 호스트에서 어긋난 건 펌웨어 11.2.1194.36에 대한 elxnet 버전 하나뿐이네요.
다른 계열이지만 교훈은 같습니다. 오랫동안 손 안 대고 돌아가던 Emulex LPe31000/LPe32000 FC 포트 페어가 Proxmox 커널이 5.15.64로, 나중엔 5.15.74로 올라간 뒤로 LUN을 전혀 못 보게 됐습니다. 케이블도 옵틱도 전혀 안 건드렸는데, 로그에는 이렇게 찍혔습니다.
이건 광학적 고장이 아니라 호스트 쪽 lpfc 리그레션이고, 5.15.60 이후 커널에서 나타났습니다. 부팅 커널을 예전 걸로 고정하는 게 프로덕션에서 버텨준 우회책이었습니다.
5.15 브랜치를 떠나도 상관없는 사람들한테는 옵트인 5.19 커널도 통했습니다. 수정은 5.15.77에 들어갈 예정이었는데, 저는 그 빌드를 직접 돌려본 적이 없어서 이건 전해들은 얘기로 받아들이세요. 요점은 그대로입니다. 잘 되던 링크가 호스트에서 뭔가 바뀐 직후에 죽으면, 트랜시버 근처에 가기 전에 호스트 변경 로그부터 읽으세요.
이것과 거울상인 경우도 덧붙입니다. 같은 반사 반응을 훈련시켜 주니까요. 인디케이터는 소프트웨어고, 소프트웨어는 양쪽 방향 다 틀릴 수 있습니다.
EX3400과 EX2300에는 Junos 결함 PR1428703이 있는데, 링크가 진짜로 up이고 트래픽도 오가는데 SFP+랑 SFP 포트 LED가 꺼진 채로 있습니다. 15.1X53에서 18.1이랑 19.x 트레인으로 옮기면서 이걸 겪은 사람이 많고, 대부분 DAC였습니다. CLI가 패널이랑 다른 말을 합니다.
물리적으로는 꺼져 있는데 LED가 Green이라고 보고합니다. 일부 빌드는 fixed로 보고됐고 다른 빌드에서는 계속 dark LED가 보고돼서, 깔끔하게 해결됐다고 말하진 않겠습니다.
님 경우는 링크 없이 켜져 있는 거고, 그건 링크 있이 꺼져 있는 거네요. 어느 쪽이든 인디케이터는 절대 믿지 말고 반대편이랑 카운터를 믿으세요.
이제 두 호스트 다 드라이버가 11.2.1149.0입니다. 케이블을 뽑으면 LED가 꺼지고, esxcli는 link down을 보고하고, standby 업링크가 원래 그래야 했던 대로 넘겨받습니다. 테스트로 각 업링크를 따로 돌려봤는데 vMotion도 깔끔하게 됐고요.
드라이버-펌웨어 페어는 이제 저희 서버 유지보수 체크리스트에 들어갔습니다. 다음 번들이 조용히 둘을 다시 갈라놓지 않게요.