Bộ điều hợp mạng Windows Server 2008 R2 ngừng hoạt động, yêu cầu khởi động lại cứng

Phiên bản TL; DR: Hóa ra đây là một lỗi mạng Broadcom sâu trong Windows Server 2008 R2. Thay thế bằng phần cứng Intel đã sửa nó. Chúng tôi không sử dụng phần cứng Broadcom nữa. Không bao giờ.

Chúng tôi đã sử dụng HAProxy cùng với nhịp tim từ dự án Linux-HA. Chúng tôi đang sử dụng hai phiên bản linux để cung cấp chuyển đổi dự phòng. Mỗi máy chủ có IP công cộng riêng và một IP duy nhất được chia sẻ giữa hai máy bằng giao diện ảo (eth1: 1) tại IP: 69.59.196.211

Giao diện ảo (eth1: 1) IP 69.59.196.211 được định cấu hình là cổng cho các máy chủ windows phía sau chúng và chúng tôi sử dụng ip_forwarding để định tuyến lưu lượng.

Chúng tôi đang gặp sự cố ngừng mạng thỉnh thoảng trên một trong các máy chủ windows phía sau cổng linux của chúng tôi. HAProxy sẽ phát hiện máy chủ đang ngoại tuyến mà chúng tôi có thể xác minh bằng cách từ xa đến máy chủ bị lỗi và cố gắng ping cổng:

Ping 69.59.196.211 với 32 byte dữ liệu:
Trả lời từ 69.59.196.220: Máy chủ đích không thể truy cập được.

Chạy arp -atrên máy chủ bị lỗi này cho thấy rằng không có mục nhập cho địa chỉ cổng (69.59.196.211):

Giao diện: 69.59.196.220 --- 0xa
Địa chỉ Internet Loại địa chỉ vật lý
69.59.196.161 00-26-88-63-c7-80 động
69.59.196.210 00-15-5d-0a-3e-0e động
69.59.196.212 00-21-5e-4d-45-c9 động
69.59.196.213 00-15-5d-00-b2-0d động
69.59.196.215 00-21-5e-4d-61-1a động
69.59.196.217 00-21-5e-4d-2c-e8 động
69.59.196.219 00-21-5e-4d-38-e5 động
69.59.196.221 00-15-5d-00-b2-0d động
69.59.196.222 00-15-5d-0a-3e-09 động
69.59.196.223 ff-ff-ff-ff-ff-ff tĩnh
224.0.0.22 01-00-5e-00-00-16 tĩnh
224.0.0.252 01-00-5e-00-00-fc tĩnh
Tĩnh 225.0.0.1 01-00-5e-00-00-01

Trên các phiên bản cổng linux của chúng tôi arp -ahiển thị:

pic-colo-196-220.peak.org (69.59.196.220) tại <không đầy đủ> trên eth1
stackoverflow.com (69.59.196.212) lúc 00: 21: 5e: 4d: 45: c9 [ether] trên eth1
pic-colo-196-215.peak.org (69.59.196.215) lúc 00: 21: 5e: 4d: 61: 1a [ether] trên eth1
pic-colo-196-219.peak.org (69.59.196.219) lúc 00: 21: 5e: 4d: 38: e5 [ether] trên eth1
pic-colo-196-222.peak.org (69.59.196.222) lúc 00: 15: 5d: 0a: 3e: 09 [ether] trên eth1
pic-colo-196-209.peak.org (69.59.196.209) lúc 00: 26: 88: 63: c7: 80 [ether] trên eth1
pic-colo-196-217.peak.org (69.59.196.217) lúc 00: 21: 5e: 4d: 2c: e8 [ether] trên eth1

Tại sao arp thỉnh thoảng đặt mục nhập cho máy chủ bị lỗi này là <không đầy đủ>? Chúng ta có nên xác định mục arp của chúng tôi tĩnh? Tôi đã luôn để arp một mình vì nó hoạt động 99% thời gian, nhưng trong trường hợp này có vẻ như nó bị lỗi. Có bất kỳ bước khắc phục sự cố bổ sung nào chúng tôi có thể giúp giải quyết vấn đề này không?

Những điều chúng tôi đã thử

Tôi đã thêm một mục arp tĩnh để thử nghiệm trên một trong các cổng linux mà vẫn không giúp được.

root@haproxy2:~# arp -a
peak-colo-196-215.peak.org (69.59.196.215) at 00:21:5e:4d:61:1a [ether] on eth1
peak-colo-196-221.peak.org (69.59.196.221) at 00:15:5d:00:b2:0d [ether] on eth1
stackoverflow.com (69.59.196.212) at 00:21:5e:4d:45:c9 [ether] on eth1
peak-colo-196-219.peak.org (69.59.196.219) at 00:21:5e:4d:38:e5 [ether] on eth1
peak-colo-196-209.peak.org (69.59.196.209) at 00:26:88:63:c7:80 [ether] on eth1
peak-colo-196-217.peak.org (69.59.196.217) at 00:21:5e:4d:2c:e8 [ether] on eth1
peak-colo-196-220.peak.org (69.59.196.220) at 00:21:5e:4d:30:8d [ether] PERM on eth1

root@haproxy2:~# arp -i eth1 -s 69.59.196.220 00:21:5e:4d:30:8d
root@haproxy2:~# ping 69.59.196.220
PING 69.59.196.220 (69.59.196.220) 56(84) bytes of data.
--- 69.59.196.220 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6006ms

Khởi động lại máy chủ web windows giải quyết vấn đề này tạm thời mà không có thay đổi nào khác đối với mạng nhưng kinh nghiệm của chúng tôi cho thấy vấn đề này sẽ quay trở lại.

Trao đổi card mạng và thiết bị chuyển mạch

Tôi nhận thấy đèn liên kết trên cổng của công tắc cho máy chủ windows bị lỗi đang chạy ở tốc độ 100Mb thay vì 1Gb trên giao diện bị lỗi. Tôi đã chuyển cáp sang một số cổng mở khác và liên kết chỉ ra 100Mb cho mỗi cổng mà tôi đã thử. Tôi cũng đổi cáp với kết quả tương tự. Tôi đã thử thay đổi các thuộc tính của card mạng trong windows và máy chủ bị khóa và yêu cầu thiết lập lại cứng sau khi nhấp vào áp dụng. Máy chủ windows này có hai giao diện mạng vật lý, vì vậy tôi đã đổi cáp và cài đặt mạng trên hai giao diện để xem sự cố có tuân theo giao diện không. Nếu giao diện công cộng bị hỏng lần nữa, chúng tôi sẽ biết rằng đó không phải là vấn đề với card mạng.

(Chúng tôi cũng đã thử một công tắc khác mà chúng tôi có trong tay, không thay đổi)

Thay đổi phiên bản trình điều khiển phần cứng mạng

Chúng tôi đã có cùng một vấn đề với trình điều khiển Broadcom mới nhất, cũng như trình điều khiển tích hợp sẵn có trong Windows Server 2008 R2.

Thay thế cáp mạng

Như một nỗ lực cuối cùng, chúng tôi nhớ một thay đổi khác xảy ra là thay thế tất cả các dây vá giữa các máy chủ / công tắc của chúng tôi. Chúng tôi đã mua hai bộ, một bộ màu xanh có độ dài 1ft - 3ft cho các giao diện riêng và một bộ cáp đỏ khác cho các giao diện công cộng. Chúng tôi đã trao đổi tất cả các cáp vá giao diện công cộng với một thương hiệu khác và chạy các máy chủ của chúng tôi mà không gặp sự cố trong cả tuần ... aaaaaand sau đó vấn đề tái phát.

Vô hiệu hóa tổng kiểm tra giảm tải, loại bỏ TProxy

Chúng tôi cũng đã thử vô hiệu hóa tổng kiểm tra TCP / IP trong trình điều khiển, không thay đổi. Bây giờ chúng tôi đang rút TProxy và chuyển sang x-forwarded-forsắp xếp mạng truyền thống hơn mà không cần viết lại địa chỉ IP ưa thích nào. Chúng tôi sẽ xem nếu điều đó giúp.

Chuyển đổi nhà cung cấp ảo hóa

Nếu không may, điều này có liên quan đến Hyper-V theo một cách nào đó (chúng tôi lưu trữ máy ảo Linux trên đó), chúng tôi đã chuyển sang VMWare Server. Không thay đổi.

Chuyển đổi mô hình máy chủ

Chúng tôi đã đạt đến cuối sợi dây xử lý sự cố và hiện đang chính thức liên quan đến hỗ trợ của Microsoft. Họ đề nghị thay đổi mô hình máy chủ:

• http://en.wikipedia.org/wiki/host_model
• http://technet.microsoft.com/en-us/magazine/2007.09.cableguy.aspx

Chúng tôi đã làm điều đó và chúng tôi cũng đã nhận được một số hotfix kernel chưa được công bố có lẽ đã được đưa vào 2008 R2 SP1. Không sửa.

Thay thế phần cứng card mạng

Cuối cùng, việc thay thế phần cứng mạng Broadcom bằng phần cứng mạng Intel đã khắc phục vấn đề này cho chúng tôi. Vì vậy, tôi có xu hướng nghĩ rằng trình điều khiển Broadcom Windows Server 2008 R2 có lỗi!

http://blog.serverfault.com/post/broadcom-die-mutha/

Từ http://linux-ip.net/html/ether-arp.html :

Nếu không có mục bộ đệm ARP tồn tại cho IP đích được yêu cầu, hạt nhân sẽ tạo các yêu cầu ARP mcast_solicit cho đến khi nhận được câu trả lời. Trong giai đoạn khám phá này, mục bộ đệm ARP sẽ được liệt kê ở trạng thái không đầy đủ. Nếu việc tra cứu không thành công sau số lượng yêu cầu ARP được chỉ định, mục nhập bộ đệm ARP sẽ được liệt kê ở trạng thái không thành công. Nếu việc tra cứu không thành công, kernel sẽ đưa phản hồi vào bộ đệm ARP và đặt lại bộ xác nhận và cập nhật bộ hẹn giờ.

Có vẻ như hộp cổng của bạn không phản hồi (hoặc phản hồi quá chậm) với các yêu cầu ARP từ hộp cổng của bạn. Điều đó <incomplete>cuối cùng có chuyển sang <failed>? Bạn có phần cứng mạng nào giữa máy chủ và cổng? Có thể các yêu cầu ARP quảng bá đang được lọc hoặc chặn ở đâu đó giữa hai máy chủ không?

Điều đó có nghĩa là bạn đã ping địa chỉ, IP có bản ghi PTR (do đó là tên) nhưng không có gì phản hồi từ máy đang nghi vấn. Khi chúng ta thấy điều này phổ biến nhất là do mặt nạ mạng con được đặt không chính xác - hoặc trong trường hợp IP bị ràng buộc với giao diện loopback vô tình bị ràng buộc với giao diện eth thay thế.

196.220 là gì? Mối quan hệ của nó với 196.211 là gì? Tôi giả sử rằng .220 là một trong những máy chủ HA Proxy. Khi bạn chạy ifconfig -a & arp -a, nó hiển thị cái gì?

Như Max Clark nói, <không đầy đủ> chỉ có nghĩa là 69.59.196.211 đã đưa ra yêu cầu ARP cho 69.59.196.220 và chưa nhận được phản hồi. (Trong Windows-Land, bạn sẽ thấy đây là ánh xạ ARP thành "00-00-00-00-00-00" ... Đối với tôi, BTW có vẻ kỳ lạ khi bạn không nhìn thấy ánh xạ ARP như vậy trên 69.59.196.220 cho 69.59.196.211.)

Tôi có xu hướng không thích sử dụng các mục ARP tĩnh bởi vì, theo kinh nghiệm của tôi, ARP thường hoàn thành công việc của mình mọi lúc.

Nếu là tôi, tôi sẽ đánh hơi giao diện Ethernet thích hợp trên máy Windows "không thành công" (69.59.196.220) để quan sát nó ARP'ing cho 69.59.196.211 và để quan sát cách / nếu nó đáp ứng các yêu cầu ARP từ 69.59. 196.211. Tôi cũng sẽ xem xét việc đánh hơi trên máy cổng chỉ dành cho ARP ( tcpdump -i interface-name arp) để xem lưu lượng ARP trông như thế nào từ phía máy Linux.

Tôi biết, từ blog , bạn đã có một mạng back-end và một mạng front-end. Trong những lần mất điện này, máy chủ Windows "không thành công" (69.59.196.220) có bất kỳ vấn đề nào khi giao tiếp với các máy khác trong mạng giao diện người dùng không, hay chỉ gặp sự cố khi nói chuyện với cổng của nó? Tôi tò mò nếu bạn đến máy bị lỗi thông qua mạng đầu cuối hoặc mạng phía sau khi bạn bắt gặp nó trong hành động.

Bạn đang làm gì để "giải quyết" vấn đề khi nó xảy ra?

Chỉnh sửa:

Tôi thấy từ bản cập nhật của bạn rằng bạn đang khởi động lại máy Windows "không thành công" để giải quyết vấn đề. Trước khi bạn làm điều đó vào lần tới, bạn có thể xác minh rằng máy Windows có thể "nói chuyện" trên giao diện mặt trước của nó không? Ngoài ra, lấy một bản sao của bảng định tuyến từ máy Windows ( route print) trong một lỗi. (Về cơ bản, tôi đang cố gắng xác định xem liệu trình điều khiển / trình điều khiển có chạy bon bon trên máy Windows không.)

Tài liệu này cho thấy các trạng thái khác nhau (bảng 2.1). Chưa hoàn thành có nghĩa là nó đã gửi yêu cầu ARP đầu tiên (có lẽ là sau một lần thăm dò cũ, trì hoãn, thăm dò) nhưng chưa nhận được phản hồi.

Lý do ARP tĩnh trên nút haproxy không giúp ích là máy chủ web của bạn vẫn không thể tìm ra cách quay lại cổng.

ARP tĩnh trên máy chủ web phá vỡ khả năng cho các máy chủ web của bạn chuyển đổi cổng khi một trong các nút haproxy không thành công - Tôi đoán giao diện ảo chia sẻ cùng địa chỉ MAC với eth1 của nút haproxy, vì vậy bạn sẽ gặp khó khăn mã đến một trong hai cổng vào mỗi máy chủ web.

Bạn có cài đặt phần mềm bảo mật nào trên máy chủ bị lỗi không? Tôi đã trải qua một đêm dài với máy chủ Windows 2008 có Symantec Endpoint Security trên đó - nó cài đặt một số mã lọc trong ngăn xếp mạng khiến nó không thể nhìn thấy các gói ARP của cổng. Cách khắc phục cho điều đó (như được cung cấp bởi Microsoft) là xóa mục đăng ký đã tải DLL.

Lần khác, sự cố này xảy ra, loại bỏ toàn bộ bộ điều hợp mạng khỏi trình quản lý thiết bị và cài đặt lại dường như có ích.

Vì bạn đã đặt tĩnh mục nhập arp của mình, máy chủ của bạn sẽ biết nơi tìm cổng. Tuy nhiên, nếu công tắc của bạn không biết cổng ở đâu, nó sẽ không chuyển tiếp các gói của bạn.

Âm thanh như bạn đã có một chuyển đổi xấu (hoặc nhầm lẫn) giữa HAproxy của bạn và máy chủ web của bạn. Khởi động lại nó.

Dù vậy, hoặc các máy chủ HAproxy của bạn không đồng ý về việc ai đang kiểm soát và cả hai đều trả lời tra cứu arp cho .211.

Dọc theo cùng một dòng, nếu công tắc của bạn bị quá tải, HAproxies của bạn có thể không thể liên lạc với nhau đủ nhanh và không thành công.

Lần tiếp theo sự cố này xảy ra, tôi sẽ đề nghị chạy một số gói chụp trên hai máy chủ được đề cập, để xác định lưu lượng ARP mà mỗi người trong số họ đang quan sát.

Máy HAproxy của bạn rất có thể sẽ có một số hương vị của tcpdump được cài đặt. Đối với máy Windows, bạn sẽ cần một ứng dụng WinPCAP , như Wireshark hoặc Microsoft Network Monitor .

Trên thực tế, khi nghĩ về vấn đề này, vì vấn đề có vẻ như là với ARP, bạn có khả năng có thể liên tục ghi lại tất cả lưu lượng ARP trên máy HAproxy và máy Windows đang được đề cập, với tệp thu thập cuộn (vì lý do) 10MB. Nó phải đủ lớn để đến khi bạn phát hiện ra lỗi, tệp chụp vẫn sẽ chứa lưu lượng ARP từ trước khi xảy ra lỗi. (Thật đáng để thử nghiệm bằng cách chạy chụp trong một giờ hoặc lâu hơn, để xem nó tạo ra bao nhiêu dữ liệu).

Cú pháp chụp ví dụ cho tcpdump của Linux (lưu ý, tôi không có sẵn hộp Linux để kiểm tra điều này; vui lòng kiểm tra hành vi của -C ​​và -W trước khi sử dụng trong sản xuất!):

tcpdump -C 10 -i eth1 -w /var/tmp/arp.cap -W 1 arp

Điều này hy vọng sẽ cung cấp cho bạn một số dấu hiệu cho thấy chính xác những gì đang thất bại. Khi một mục ARP hết hạn (và theo bài viết này , các phiên bản Windows mới hơn dường như hết hạn các mục 'không hoạt động'), tôi sẽ mong đợi những điều sau đây sẽ xảy ra:

1. Máy chủ nguồn sẽ gửi yêu cầu ARP đến máy chủ đích. Các yêu cầu ARP thường được phát, nhưng trong trường hợp máy chủ đang làm mới một mục hiện có, ARP có thể được gửi đi.
2. Máy chủ đích sẽ trả lời bằng một câu trả lời ARP. 99% thời gian này sẽ là unicast, nhưng RFC cho phép phản hồi phát sóng. (Xem thêm RFC về Phát hiện va chạm địa chỉ IPv4 để biết thêm chi tiết).

Nghe có vẻ đơn giản, có một loạt những thứ khác có thể can thiệp vào quá trình này:

• Yêu cầu ban đầu có thể không đến đích.
• Yêu cầu có thể đến đích, nhưng phản hồi có thể không đến được nguồn.
• Một số loại cơ chế sẵn sàng cao có thể can thiệp vào hành vi 'bình thường' của ARP:
  • Làm thế nào để chuyển đổi dự phòng giữa các nút HAProxy hoạt động? Liệu nó có sử dụng một địa chỉ MAC được chia sẻ hay nó sử dụng ARP vô cớ để thất bại một địa chỉ IP giữa các nút?
  • Rất nhiều địa chỉ MAC trong các bảng ARP ở trên bắt đầu bằng 00-15-5D, được đăng ký rõ ràng cho Microsoft. Bạn có đang sử dụng bất kỳ hình thức phân cụm hoặc HA nào khác trên máy Windows không? Các địa chỉ MAC 00-15-5D này có giống với các địa chỉ mà bạn thấy được liên kết với các NIC phần cứng khi bạn thực hiện 'ipconfig / all' trên máy chủ Windows không?

Những điều cần kiểm tra nếu / khi điều này xảy ra một lần nữa:

• Nhìn vào các gói chụp lưu lượng ARP; Có phần nào của cuộc trò chuyện rõ ràng không xảy ra?
• Kiểm tra các cầu nối / bảng CAM của công tắc; tất cả các địa chỉ MAC trong bản đồ câu hỏi đến các cổng mà bạn mong đợi?
• Các máy chủ khác trên mạng con có các mục ARP hợp lệ cho các địa chỉ IP của cả máy chủ Windows và HAProxy không?
• Các mục ARP cho cùng một IP mục tiêu trên nhiều máy nguồn khác nhau có phân giải cùng một địa chỉ MAC không? tức là đăng nhập vào một vài máy chủ khác trên mạng con và xác minh rằng 196.211 phân giải đến cùng một địa chỉ MAC trên cả hai.

Chúng tôi đã gặp sự cố tương tự với một trong các máy chủ đầu cuối 2008 R2 của chúng tôi, nơi tất cả lưu lượng truy cập trên NIC sẽ dừng nhưng vẫn được kết nối và đèn LED NIC sẽ hiển thị thông tin. Đây là một vấn đề đang diễn ra liên tục cắt xén 2-3 lần một tuần, nhưng chỉ sau khoảng 12-13 giờ hoạt động (máy chủ được khởi động lại hàng đêm).

Tôi thấy Seriousbit Netbalancer là nguyên nhân, sau khi tôi thử (vì tò mò) chấm dứt dịch vụ NetbalancerService. Lưu lượng truy cập sau đó bắt đầu di chuyển trên giao diện. Tôi đã gỡ cài đặt Netbalancer.

Tôi gặp vấn đề tương tự với Asus Mainboard lan. Nó đã được sửa bằng cách cài đặt trình điều khiển mới nhất từ trang web realtek