Sự cố chuyển đổi nhịp tim cụm Cisco Catalyst - tăng lỗi đầu vào

VẤN ĐỀ: Các máy chủ trong hai cụm liên tục mất kết nối nhịp tim với nhau do đó gây ra sự cố ngừng cơ sở dữ liệu. Mất điện ngắn ngủi nhưng gây rối.

THIẾT LẬP:

• Có hai cụm ba máy chủ mỗi.
• Mỗi máy chủ có một NIC được kết nối với một công tắc Lớp 2 (Catalyst 2950) với các cổng chuyển đổi được mã hóa cứng ở mức 100Mb / song công hoàn toàn.
• Các DBA xác nhận rằng mỗi NIC nhịp tim được mã hóa cứng thành 100Mb / song công hoàn toàn.
• Có hai cụm được cấu hình trong Vlan 100 và trong cùng một mạng con (10.40.60.0/24).
• Địa chỉ IP quản lý nằm trên một mạng con riêng biệt (10.40.1.0/24) và cổng chuyển đổi của nó nằm trong Vlan 1.

TRIỆU CHỨNG:

• Tôi thấy số lỗi ngày càng tăng trên các cổng chuyển đổi. Đối với ba máy chủ trong một cụm, các lỗi đầu vào (tất cả CRC) là khoảng 3% tổng số gói đầu vào. Không có lỗi đầu ra. Các cụm khác là khoảng 6% tổng số gói đầu vào.
• Truyền và nhận tải trên các cổng chuyển đổi là nhẹ, dưới 20/255 trên txload và rxload.
• Nhật ký chuyển đổi hiển thị các cổng chuyển đổi nảy:

  16 tháng 5 11:15:31 PDT:% LINEPROTO-5-UPDOWN: Giao thức đường truyền trên Giao diện FastEthernet0 / 13, đã thay đổi trạng thái xuống
  16 tháng 5 11:15:32 PDT:% LINK-3-UPDOWN: Giao diện FastEthernet0 / 13, đã thay đổi trạng thái xuống
  ngày 16 tháng 5 11:15:34 PDT:% LINK-3-UPDOWN: Giao diện FastEthernet0 / 13, đã thay đổi trạng thái thành
  ngày 16 tháng 5 11:15:35 PDT:% LINEPROTO-5-UPDOWN: Giao thức đường truyền trên Giao diện FastEthernet0 / 13, thay đổi trạng thái lên

• Tôi đã thay thế cáp Cat5 cũ giữa máy chủ nhịp tim NIC và công tắc bằng Cat6 mới - không có hiệu lực.
• Tôi đã tạo một Vlan 200 mới trong một mạng con mới (10.40.61.0/24) và có các DBA tái IP IP các nhịp tim của họ trên một cụm - không có hiệu lực.
• Chúng tôi đã thử mọi sự kết hợp giữa tốc độ và song công trên cổng chuyển đổi và NIC - không có hiệu lực, đã quay trở lại 100Mb / full-duplex trên cả hai.
• Các DBA đã nâng cấp trình điều khiển Broadcom trên cả hai cụm lên mức mới nhất - giảm tỷ lệ lỗi trên cụm 6% xuống còn 4%, cụm còn lại vẫn ở mức 3%.

CÁC BƯỚC TIẾP THEO CỦA TÔI:

• Có các máy ảo Intel trên các máy chủ. Hãy thử di chuyển nhịp tim của cụm sang một Intel Intel. Có lẽ đó là một vấn đề Broadcom?
• Thay đổi công tắc thành một công tắc có khả năng biểu diễn. Có một Catalayst 3560x có sẵn, nhưng lấy nó sẽ trì hoãn một dự án. Có lẽ gig trên cổng chuyển đổi và NIC sẽ chơi đẹp hơn?

Ý nghĩ gì?

Có cái gì tôi có thể cấu hình trên công tắc 2950 hiện có để giảm thiểu lỗi không? Tôi nên thực hiện các bước khắc phục sự cố bổ sung nào?

Lỗi CRC thường là vấn đề cáp. Dưới đây là những điều tôi sẽ kiểm tra tiếp theo trước khi hoán đổi phần cứng:

• Là các máy chủ được kết nối trực tiếp với chuyển đổi hoặc chúng kết nối thông qua một số loại cáp cơ sở hạ tầng? Nếu vậy, có được các cáp cơ sở hạ tầng được chứng nhận lại.
• Nếu bạn có một máy kiểm tra cáp thực sự (không phải là máy kiểm tra tính liên tục đơn giản), tôi sẽ kiểm tra các loại cáp.
• Nếu dây cáp được làm bằng tay, tôi sẽ thay thế bằng dây cáp sản xuất tại nhà máy. Thường gặp phải các loại vấn đề với dây cáp làm bằng tay.
• Kiểm tra xem có nguồn EM nào gần dây cáp chạy không. Đường dẫn lại cáp nếu bạn thậm chí có thể tạm thời để đảm bảo chúng được tách biệt khỏi nguồn điện hoặc các nguồn EM khác.

Ngoài ra, tôi sẽ bắt đầu tại các NIC như bạn đã chỉ ra. Có thể bạn có một số từ một chạy xấu.

Tôi sẽ khuyên bạn nên thử nghiệm bằng cách chuyển sang Intel NIC như bạn đã đề xuất. Tôi đã gặp phải các vấn đề tương tự trong đó một tỷ lệ nhỏ lưu lượng truy cập là lỗi đầu vào. Chúng tôi gặp sự cố khi xử lý sự cố bằng cách đặt một trung tâm câm giữa máy chủ (trong trường hợp của tôi là camera) và công tắc. Nếu công tắc không còn thấy bất kỳ lỗi đầu vào nào thì vấn đề là máy chủ NIC.

Tôi đã thử nhiều bước tương tự mà bạn đã đề xuất. Trong trường hợp của tôi, nó hóa ra là một hoạt động sản xuất tồi. Điều duy nhất khắc phục vấn đề là thay thế NIC (máy ảnh).