OCe14000 LoM báo link up dù đã rút cáp, nên ESXi teaming không bao giờ failover
Cluster vSphere nhỏ, hai uplink 10G mỗi host vào một cặp switch top-of-rack. Sau khi ToR được reboot để update firmware, một phần VM trên một host im bặt và vMotion fail trên cả hai uplink - vậy mà ESXi chẳng bao giờ đánh dấu gì là down và đèn LED trên adapter vẫn sáng suốt.
- Fujitsu Primergy RX2540 M1
- adapter LAN-on-motherboard Emulex OneConnect OCe14000 (VID 10df DID 0720 SVID 1734 SSID 120e)
- ESXi 6.0 U3
- optic SFP+ nối vào ToR, teaming active/standby thường trên vSwitch
Điều khiến tôi tin đây không phải lỗi switch: tôi rút hẳn sợi quang ra khỏi adapter mà nó vẫn trông như đang sống.
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Đã thử:
- tháo lắp lại optic và sợi quang, đổi dây patch
- chuyển uplink sang ToR switch còn lại, port ở đó down đúng như dự kiến
- restart management agent trên host
Vì host tin rằng uplink vẫn sống, chính sách teaming không có lý do gì để chuyển bất cứ thứ gì và VM cứ ghim ở một port đã chết. Đây có phải vấn đề driver-đối-firmware đã biết trên OneConnect, hay tôi nên xem xét phần cứng 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
Tổ hợp đó là lỗi của bạn, và nó không nằm trong danh sách cặp được hỗ trợ cho ESXi 6.0. Adapter rơi vào trạng thái sống dở chết dở: nó ngừng chuyển traffic nhưng vẫn tiếp tục báo port là connected, nên chính sách teaming không bao giờ nhận được sự kiện down mà nó cần để hành động. Đó là lý do bạn gặp phải một kiểu cô lập một phần với vMotion chết trên cả hai uplink thay vì một lỗi NIC trung thực - một card chết đàng hoàng dễ sống sót hơn nhiều so với một card nói dối.
Nâng driver lên 11.2.1149.0. Đó là bản elxnet đã được qualify với firmware 11.2.1194.36 trong compatibility list của VMware, nên bạn đang đưa driver lên để khớp với firmware chứ không phải hạ card xuống. Sau đó xác nhận lại bằng hai lệnh bạn đã có sẵn:
Dòng vib phải hiện phiên bản mới, và Link Status phải theo đúng trạng thái cáp trở lại một khi host lên lại. Test bằng cách rút sợi quang trong khi có một VM đang chạy trên uplink đó, trước khi tin tưởng giao cả cluster cho nó.
Thói quen đáng mang theo: trên OneConnect driver và firmware di chuyển theo cặp, nên lên lịch cả hai cùng nhau thay vì để một gói maintenance kéo một trong hai lên trước một mình. So sánh hai dòng đó chỉ tốn một lệnh, và nó phải nằm rất lâu trước khi bạn bắt đầu rút optic ra hay đổ lỗi cho switch.
Hai dòng bạn đăng chính là phần đáng chú ý: firmware 11.2.1194.36 chạy bên dưới elxnet 10.2.309.6v. Firmware đó có đến cùng một gói maintenance server vào lúc nào đó, tách riêng khỏi driver không?
Kiểm tra cặp đó với compatibility list cho ESXi 6.0, chứ không phải theo kiểu "mới nhất chắc là ổn". OneConnect là một trong những dòng mà driver và firmware được qualify theo cặp, và một cặp lệch nhau không nhất thiết fail ồn ào - nó chạy nửa vời, mà cái đó còn tệ hơn nhiều.
Cũng đáng nói xem port thứ hai của adapter có hành xử giống vậy khi rút cáp không.
Đúng vậy, firmware lên theo một gói maintenance server; driver thì chưa đụng tới kể từ khi host được dựng.
Cả hai port LoM hành xử giống hệt nhau: rút cáp ra, esxcli network nic get vẫn báo Link Status: Up, đèn LED vẫn sáng, và vSwitch vẫn giữ uplink trong danh sách active. Phía switch thì sạch và port của nó rớt ngay khi tôi rút cáp.
Vậy thứ duy nhất lệch nhịp trên host này là phiên bản elxnet so với firmware 11.2.1194.36.
Dòng khác, nhưng cùng bài học. Một cặp port FC Emulex LPe31000/LPe32000 chạy yên ổn không đụng tới suốt bao lâu bỗng không thấy LUN nào nữa sau khi kernel Proxmox lên 5.15.64 rồi sau đó 5.15.74. Cáp và optic không hề đụng tới, và log ghi:
Đó là một regression của lpfc ở phía host, không phải lỗi quang; nó xuất hiện ở các kernel sau 5.15.60. Pin boot kernel về lại là cách workaround đã trụ vững trong production:
Kernel 5.19 opt-in cũng có tác dụng với những ai không ngại rời khỏi nhánh 5.15. Bản sửa được cho là sẽ lên 5.15.77, nhưng tôi chưa từng thực sự chạy thử bản đó, nên cứ coi đây là nghe kể lại. Điểm mấu chốt vẫn vậy: khi một link vốn chạy tốt chết ngay sau khi có gì đó thay đổi trên host, hãy đọc change log của host trước khi lại gần transceiver.
Thêm hình ảnh ngược lại của chuyện này, vì nó luyện cùng một phản xạ. Đèn báo là software, và software sai theo cả hai chiều.
Trên EX3400 và EX2300 có một lỗi Junos, PR1428703, khiến đèn LED port SFP+ và SFP vẫn tối trong khi link thực sự đang up và truyền traffic bình thường. Người ta gặp phải khi chuyển từ 15.1X53 lên các nhánh 18.1 và 19.x, chủ yếu với DAC. CLI không khớp với panel:
báo LED là Green trong khi đèn vật lý thì tắt. Một số bản build được báo là đã fix và đèn tối vẫn tiếp tục được báo trên các bản khác, nên tôi sẽ không gọi đây là đã đóng gọn gàng.
Của bạn thì sáng mà không có link, của tôi thì tối mà có link. Dù kiểu nào, hãy tin đầu bên kia và counter, đừng bao giờ tin đèn báo.
Driver giờ đã ở 11.2.1149.0 trên cả hai host. Khi rút cáp, đèn LED tắt, esxcli báo link down, và uplink standby tiếp quản đúng như nó luôn phải làm - vMotion chạy sạch qua từng uplink riêng biệt khi test.
Cặp driver-và-firmware giờ được đưa vào checklist maintenance server của chúng tôi để gói tiếp theo không lặng lẽ tách chúng ra nữa.